Revisamos de forma completamente cada artículos de nuestra web con el objetivo de enseñarte en todo momento la información más veraz y certera.
Solución:
Puede usar FileVersionInfo.FileVersion para obtener esto de una ruta.
var versionInfo = FileVersionInfo.GetVersionInfo(pathToExe);
string version = versionInfo.FileVersion; // Will typically return "1.0.0.0" in your case
Actualizado y modernizado 2018 (p. ej. string interpolación de C#6):
La respuesta aceptada es parcialmente incorrecta (ProductVersion no suele devolver una versión de tres partes) y un poco engañosa:
Aquí hay una respuesta más completa. Para que el texto principal no sea demasiado extenso, lo dividí en un resumen más corto que puede ser “suficiente” para muchas personas. No está obligado a leer la segunda parte detallada, así que no tl; dr 🙂
Breve resumen:
-
Hay diferentes versiones (versión de ensamblaje, versión de archivo, versión de producto) de cada archivo, pero normalmente tenerlos todos iguales para no obtener la “versión infierno” ya en el nivel de archivo (llegará lo suficientemente pronto).
-
La versión del archivo (que es visible en Explorer y se usa en configuraciones/instalaciones) es lo que yo nombraría como el más importante para molestar.
-
Para lograr esto, simplemente comente la versión del archivo en AssemblyInfo.cs archivo como se muestra a continuación. ¡Esto asegura que las tres posibles versiones diferentes de un archivo sean iguales!
[assembly: AssemblyVersion(“1.1.2.“)]
//[assembly: AssemblyFileVersion(“1.1.2.“)]
-
Por ejemplo, para el control de versiones semántico, desea obtener solo 3 partes de versión de 4 posibles:
Tener un recuento automático de compilaciones para cada compilación de Visual Studio es útil. Pero este conteo de compilación no siempre es útil para informar a sus clientes, internos o externos. Entonces, para mencionar la versión del archivo en Windows, en los cuadros de diálogo de título, recomendaría mostrar solo tres partes v1.2.3 (y, por supuesto, con versiones semánticas):
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 = $"VversInfo.FileMajorPart.versInfo.FileMinorPart.versInfo.FileBuildPart";
string fileVersionFull2 = $"VversInfo.FileMajorPart.versInfo.FileMinorPart.versInfo.FileBuildPart.versInfo.FilePrivatePart";
FileVersionFull2 solo muestra cómo manejar las 4 partes, excepto la “V” que contiene lo mismo que FileVersionFull .
Detalles:
Primero hay una hoja de trucos sobre cómo obtener y configurar las tres versiones:
Versión del archivo: [assembly: AssemblyFileVersion(..)] => Sistema.Diagnósticos.FileVersionInfo.FileVersion
Version del producto: [assembly: AssemblyInformationalVersion(..)] => System.Diagnostics.FileVersionInfo.ProductVersion
Versión de montaje: [assembly: AssemblyVersion(..)] => Sistema.Reflexión.Ensamblaje.Versión
Especialmente el incumplimiento puede ser confuso. Enlace SO recomendado para comprender los detalles: FileVersionInfo y AssemblyInfo
EntryAssembly frente a ExecutingAssembly
Para considerar completamente cada caso para obtener la versión de la aplicación en ejecución, busque en otro lugar para obtener más detalles, por ejemplo, aquí: Cuál es mejor para obtener la ubicación de ensamblaje, GetAssembly().Location o GetExecutingAssembly().Location
Especialmente, puede haber confusión, si se debe usar EntryAssembly o ExecutingAssembly. Ambos tienen ventajas y advertencias. Si tiene el siguiente código que no está en el mismo ensamblado que el .exe, por ejemplo, en un ensamblado auxiliar, las cosas se complican más. Por lo general, usaría EntryAssembly para obtener la versión del .exe.
Pero: para las pruebas unitarias en Visual Studio para probar rutinas en un proyecto .exe paralelo, GetEntryAssembly() no funciona (mi entorno: NUnit, VS2017). Pero GetExecutingAssembly() no falla al menos, solo durante la prueba unitaria obtienes la versión ensamblada del proyecto de prueba. Bastante bien para mí. Puede haber situaciones que no son tan simples.
Si lo desea, puede omitir la declaración como static haciendo realmente posible obtener versiones de varios ensamblajes diferentes en un solo programa.
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);
..
Versión del producto frente a versión del archivo:
La versión del producto de un archivo también se muestra en el Explorador de Windows. Recomendaría diferenciar al máximo ProductVersion y FileVersion en el archivo más “visible para el cliente” (principalmente el .exe principal de la aplicación). Pero, por supuesto, podría ser una opción diferenciar para cada archivo de la aplicación “principal” y permitir que todos tengan toda la ProductVersion de “marketing” que ve el cliente. Pero la experiencia demuestra que no es necesario ni barato intentar sincronizar demasiado las versiones técnicas y las versiones de marketing. La confusión no disminuye realmente, los costos aumentan. Entonces, la solución descrita en la primera parte aquí debería hacerlo principalmente.
Historial: versión de ensamblaje frente a versión de archivo:
Una razón para tener diferentes versiones es también que un ensamblado .NET puede constar originalmente de varios archivos (módulos), teóricamente. Visual Studio no lo usa y rara vez se usa en otros lugares. Esta puede ser una de las razones históricas de dar la posibilidad de diferenciar estas dos versiones. Técnicamente, la versión ensamblada es relevante para el control de versiones relacionado con .NET como versiones GAC y Side-by-side, la versión de archivo es más relevante para configuraciones clásicas, por ejemplo, sobrescritura durante actualizaciones o para archivos compartidos.
En la respuesta aceptada se hace referencia a “pathToExe”.
Esta ruta se puede recuperar y utilizar de la siguiente manera:
var assembly = Assembly.GetExecutingAssembly();
var fvi = FileVersionInfo.GetVersionInfo(assembly.Location);
var version = fvi.FileVersion; // or fvi.ProductVersion
Espero que esto evite que alguien haga algunos pasos adicionales innecesarios.
Nos puedes auxiliar nuestra función fijando un comentario y dejando una valoración te estamos agradecidos.