2009-08-20 7 views
13

Existe-t-il un équivalent en __DATE__ et __TIME__ en C#?Equivalent de macros __DATE__, __TIME__ en C#

Fondamentalement, ce que j'essaie de faire est de placer un horodatage de construction dans une application C#.

One possibility j'ai vu sur le site Web de Microsoft est de procéder comme suit: «. 1.0 »

Assembly assem = Assembly.GetExecutingAssembly(); 
Version vers = assem.GetName().Version; 
DateTime buildDate = new DateTime(2000, 1, 1).AddDays(vers.Build).AddSeconds(vers.Revision * 2); 
Console.WriteLine(vers.ToString()); 
Console.WriteLine(buildDate.ToString()); 

Cependant, cela ne fonctionne que si votre version en AssemblyInfo.cs est, que la nôtre ne sera pas .

Répondre

4

Je recommande de personnaliser votre script de construction pour écrire l'heure de la date dans le fichier. Le projet MSBuild Community Tasks a une tâche de temps qui peut être utilisée exactement pour cela.

+0

Merci, cela ressemble à la manière la plus simple d'insérer l'horodatage quelque part. –

+0

A part «l'insertion de l'horodatage», il est possible d'extraire un horodatage déjà inséré. Voir http://stackoverflow.com/questions/1600962/displaying-the-build-date pour obtenir le code de l'éditeur de liens. Probablement bon jusqu'à ce que les en-têtes des fichiers PE et COFF soient modifiés. –

2

Si vous essayez de générer automatiquement vos numéros de build et de révision, je regarderais dans le projet suivant sur CodePlex:

http://autobuildversion.codeplex.com/

+0

Je ne cherche pas à générer des numéros de version car nous avons déjà une convention préexistante à respecter. Juste voudrais intégrer l'heure de compilation quelque part dans l'application. –

+0

Par curiosité, pourquoi avez-vous besoin du temps de construction intégré? – jrista

+0

Pas vraiment de raison, j'ai souvent trouvé pratique d'avoir une sorte de temps de compilation imprimé car nos numéros de version ne se bousculent pas avec chaque build que nous faisons. –

1

Vous pouvez regarder la personnalisation des projets fichier .csproj. C'est juste un fichier msbuild ordinaire et vous pouvez vous connecter à la cible BeforeBuild pour générer ou mettre à jour un fichier, en stockant peut-être cette valeur dans un attribut de niveau d'assembly personnalisé.

J'imagine que les tâches de la communauté msbuild seraient utiles ici car elles ont plusieurs tâches utiles pour des choses comme le remplacement de jeton dans un fichier.

0

laid, et nécessite certaines autorisations, mais si cela est à usage interne:

  // assume the relevant using statements above... 
      FileVersionInfo vi = FileVersionInfo.GetVersionInfo(Assembly.GetExecutingAssembly().Location); 
      FileInfo fileInfo = new System.IO.FileInfo(vi.FileName); 
      DateTime createTime = fileInfo.CreationTime; 
0

DateTime DATE = File.GetLastWriteTime (Application.ExecutablePath);

1

Réponse courte: NO. Il n'y a pas d'équivalent. Ils l'ont laissé dehors. Dommage. Blague sur toi.

Il existe des solutions de rechange quasi-équivalentes, toutes basées sur l'examen du programme lui-même. Aucun n'est rationnel, élégant ou robuste. Certaines solutions ramassent la date de compilation + l'heure de "AssemblyVersion", une structure de quatre champs UInt16 ("Version Majeure", "Version Mineure", "Numéro de Build", et "Révision") que ne sont pas garantis pour contenir la date et l'heure du tout, et encore moins dans un format spécifique. Si vous définissez AssemblyVersion sur "ab *" (et que personne ne le change), le compilateur le remplace par abcd, où c == days et d * 2 == secondes depuis le 1er janvier 2000 à 00:00 (heure locale) , mais ne tient pas compte de l'heure d'été), au moment où il analyse AssemblyInfo.cs. Ceux-ci sont compilés dans le programme, où ils peuvent être accessibles via System.Reflection.Assembly.GetExecutingAssembly(). GetName(). Version.

D'autres solutions ont le fichier exécutable à atteindre dans le système de fichiers pour récupérer sa « dernière modification » date + heure de ses propres métadonnées, qui est facilement modifiée ou endommagée par le transfert via FAT, SFMC ou FTP avec Modification de l'heure d'été ou du fuseau horaire, serveurs FTP paresseux qui ignorent purement et simplement les métadonnées ou utilitaires de fichiers qui modifient les métadonnées à la demande. Pathétique.

Où est la compilation constante (ou constantes), peut-être appelé #NOW (ou #YEAR, #month, #Jour, etc.), qui peut être utilisé dans des expressions ou affecté à un const ou lecture seulement? CodeWarrior C, GCC, MS C et MS C++ donnent les macros standard prédéfinies __DATE__ et __TIME__, qui peuvent être utilisées comme des constantes de chaîne à la compilation. Cela semble être une omission flagrante de C#, qui pousse tout le monde à gaspiller des années-personnes à poser des questions et à mettre en place des solutions de rechange. Nouvelle langue, nouveau code, design rachitique pathétique. C# n'a pas de macros. #define de C# a seulement "defined" ou "undefined". ET ALORS? Je ne vois aucune excuse pour la suppression de constantes de compilation importantes. Que diriez-vous de le mettre dans le faux pro-processeur de C#? 17 ans dans "Simple Managed C"/"C-like Object Oriented Language", CIL, et CLR, et c'est ce que c'est? Un million de façons d'écrire du code qui ne fait pas ce qu'il dit (implémentation du threading)? Des bibliothèques qui exposent toutes les failles de la «méthode sous-jacente»? deux machines virtuelles distinctes:: une machine virtuelle 32 bits pour le matériel 32 bits (ou l'émulateur) et une machine virtuelle 64 bits pour le matériel 64 bits (uniquement) - ce qui est virtuel à ce sujet ? Java compile une fois, pour seulement une machine virtuelle, qui a bien sûr des implémentations séparées pour chaque plate-forme (32 ou 64).