Comment obtenir le numéro de version du fichier .exe à partir du chemin d'accès au fichier ?

Question

J'utilise .Net 3.5/4.0 avec un code en C#.

J'essaie d'obtenir le numéro de version d'un fichier exe sur mon lecteur C :.

Par exemple, le chemin est : c : \Program\demo.exe. Si le numéro de version de demo.exe est 1.0.

Comment puis-je utiliser ce chemin pour récupérer le numéro de version ?

Answer 1

Vous pouvez utiliser FileVersionInfo.FileVersion pour aller chercher ceci à partir d'un chemin.

var versionInfo = FileVersionInfo.GetVersionInfo(pathToExe);
string version = versionInfo.FileVersion; // Will typically return "1.0.0.0" in your case

Answer 2

Mise à jour et modernisation de 2018 (par exemple, l'interpolation des chaînes de caractères de C#6) :

La réponse acceptée est en partie incorrecte (ProductVersion ne renvoie généralement pas une version en trois parties) et un peu trompeuse :

Voici une réponse plus complète. Pour que le texte principal ne soit pas trop long, je l'ai divisé en un résumé plus ou moins court qui peut être "suffisant" pour beaucoup de gens. Vous n'êtes pas obligé de lire la deuxième partie détaillée, donc pas de tl;dr :-)

Résumé succinct :

1. Il existe différentes versions (version de l'assemblage, version du fichier, version du produit) de chaque fichier, mais normalement, vous allez les rendre tous égaux de ne pas subir "l'enfer des versions" déjà au niveau des fichiers (cela viendra assez tôt).

2. La version du fichier (qui est visible dans l'Explorateur et utilisée dans les installations) est, à mon avis, la plus importante à prendre en compte.

3. Pour cela, il suffit de commenter fileversion dans AssemblyInfo.cs comme ci-dessous. Cela garantit que les trois versions différentes possibles d'un fichier sont les mêmes !

   [montage : AssemblyVersion("1.1.2. ")]
   // [assemblage : AssemblyFileVersion("1.1.2. ")]

4. Par exemple, pour le versioning sémantique, vous voulez obtenir seulement 3 parties de version sur les 4 possibles :

Il est utile de disposer d'un comptage automatique des builds pour chaque build de Visual Studio. Mais ce comptage de build n'est pas toujours utile pour informer vos clients, internes ou externes. Ainsi, pour mentionner la version du fichier à Windows, dans les dialogues de titre, je conseillerais de ne montrer que trois parties v1.2.3 (et bien sûr avec un versionnement sémantique) :

using System.Diagnostics;
...

var versInfo= FileVersionInfo.GetVersionInfo(pathToVersionedFile); 
string fileVersionFull = versInfo.FileVersion; // No difference here for versinfo.ProductVersion if recommendation in AssemblyInfo.cs is followed
string fileVersionSemantic = $"V{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}";
string fileVersionFull2 =    $"V{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}.{versInfo.FilePrivatePart}";

Version complète du fichier2 montre juste comment manipuler les 4 parties, sauf le "V" qu'il contient, de la même manière que FileVersionFull .

D é t a i l s :

La première est un aide-mémoire sur la façon d'obtenir et de régler les trois versions :

Version du fichier : [assembly : AssemblyFileVersion(..)] => System.Diagnostics.FileVersionInfo.FileVersion

Version du produit : [assembly : AssemblyInformationalVersion(..)] => System.Diagnostics.FileVersionInfo.ProductVersion

Version d'assemblage : [assembly : AssemblyVersion(..)] => System.Reflection.Assembly.Version

En particulier, le défaut de paiement peut être source de confusion. Lien SO recommandé pour comprendre les détails : FileVersionInfo et AssemblyInfo

EntryAssembly vs. ExecutingAssembly
Pour étudier tous les cas de figure permettant d'obtenir la version de l'application en cours d'exécution, cherchez ailleurs pour plus de détails, par exemple ici : Quel est le meilleur moyen d'obtenir l'emplacement d'un assemblage, GetAssembly().Location ou GetExecutingAssembly().Location ?
En particulier, il peut y avoir une certaine confusion quant à l'utilisation de EntryAssembly ou de ExecutingAssembly. Ils ont tous deux des avantages et des inconvénients. Si le code suivant ne se trouve pas dans la même assembly que le .exe, par exemple dans une assembly d'aide, les choses se compliquent. En général, vous utiliserez alors EntryAssembly pour obtenir la version du fichier .exe.
Mais : Pour les tests unitaires dans Visual Studio pour tester les routines dans un projet .exe parallèle, GetEntryAssembly() ne fonctionne pas (mon env : NUnit, VS2017). Mais GetExecutingAssembly() ne plante pas au moins, seulement pendant le test unitaire vous obtenez la version assembly du projet de test. Il peut y avoir des situations qui ne sont pas aussi simples.
Si vous le souhaitez, vous pouvez omettre la déclaration en tant que statique, ce qui permet réellement d'obtenir des versions de plusieurs assemblages différents dans un seul programme.

public static class AppInfo
{
  public static string FullAssemblyName { get; }
  ..

  static AppInfo()
  {
      Assembly thisAssembly = null;
      try
      {
          thisAssembly = Assembly.GetEntryAssembly();
      }
      finally
      {
          if (thisAssembly is null)
              thisAssembly = Assembly.GetExecutingAssembly();
      }
      FullAssemblyName = thisAssembly.Location;
      var versInfo = FileVersionInfo.GetVersionInfo(FullAssemblyName);
      ..
  }
}

Version du produit et version du fichier :
La version du produit d'un fichier est également affichée dans l'explorateur Windows. Je recommanderais de différencier au maximum ProductVersion et FileVersion dans le fichier le plus "visible pour le client" (généralement le .exe principal de l'application). Mais on pourrait bien sûr choisir de différencier pour chaque fichier de l'application "principale" et de les laisser tous avoir la ProductVersion "marketing" qui est vue par le client. Mais l'expérience montre qu'il n'est ni nécessaire ni économique d'essayer de trop synchroniser les versions techniques et les versions marketing. La confusion ne diminue pas vraiment, les coûts augmentent. La solution décrite dans la première partie de ce document devrait donc suffire.

Histoire : Version de l'assemblage et version du fichier : L'une des raisons pour lesquelles il existe différentes versions est également qu'une assemblée .NET peut, à l'origine, être constituée de plusieurs fichiers (modules) - en théorie. Ceci n'est pas utilisé par Visual Studio et est très rarement utilisé ailleurs. C'est peut-être une raison historique de donner la possibilité de différencier ces deux versions. Techniquement, la version de l'assemblage est pertinente pour les versions liées à .NET comme les versions GAC et Side-by-side, la version du fichier est plus pertinente pour les configurations classiques, par exemple l'écrasement pendant les mises à jour ou pour les fichiers partagés.

Answer 3

Dans la réponse acceptée, il est fait référence à "pathToExe".

Ce chemin peut être récupéré et utilisé comme suit :

var assembly = Assembly.GetExecutingAssembly();
var fvi = FileVersionInfo.GetVersionInfo(assembly.Location);
var version = fvi.FileVersion; // or fvi.ProductVersion

J'espère que cela évitera à quelqu'un de faire des démarches supplémentaires inutiles.

Answer 4

Où Program est le nom de votre classe :

Console.WriteLine("Version = " + typeof(Program).Assembly.GetName().Version.ToString()) ;

Answer 5

Je ne sais pas si c'est ce que vous cherchez, mais.. :

http://www.daniweb.com/software-development/csharp/threads/276174/c-code-to-get-dll-version

C'est écrit,

// Get the file version info for the notepad.
FileVersionInfo myFileVersionInfo =  FileVersionInfo.GetVersionInfo(Environment.SystemDirectory + "\\notepad.exe");

// Print the file name and version number.
Console.WriteLine("File: " + myFileVersionInfo.FileDescription + '\n' + "Version number: " + myFileVersionInfo.FileVersion);