Actualmente tenemos un acalorado debate interno sobre si el nombre real del ensamblado de .NET debe incluir el número de versión del código (por ejemplo, CodeName02.exe o CompanyName.CodeName02.dll). ¿Alguien sabe de una fuente autorizada, como Microsoft, que proporciona orientación sobre este tema?¿Los nombres de ensamblados de .NET deberían incluir un número de versión?
Esto es para qué es el archivo Properties/AssemblyInfo.cs.
Hay dos versiones dentro de ese archivo, la versión del archivo y la versión de montaje:
[assembly: AssemblyVersion("1.1.0.256"]
[assembly: AssemblyFileVersion("1.1.0.256")]
Una vez que se establecen los puede utilizar para realizar un seguimiento de las versiones de ustedes binarios. Se ve fácilmente en el explorador con clic derecho-> propiedades.
Ninguno de los nombres dll o exe incluidos en las aplicaciones de Microsoft (y OS) usan esa convención.
Otros sistemas utilizarán estos números para resolver dependencias y verificar la versión. Por ejemplo, el sistema MSI actualizará los binarios en función de las propiedades de la versión.
No tengo conocimiento de nada autoritario, pero me parece que usar un nombre coherente simplificaría todo, desde el proceso de scripts de instalación hasta la documentación. Dado que uno puede almacenar la versión como metadatos en el archivo, no sé por qué sería necesario en el nombre del archivo. ¿Por qué prepararse para la molestia de tener que dar cuenta de los archivos con nombres diferentes?
La información de la versión puede estar contenido en el archivo AssemblyInfo y luego puede ser consultado a través de la reflexión, etc.
Algunos proveedores incluyen el número de versión en el nombre para que sea más fácil de ver de un vistazo lo que es. Los nombres dll de Microsoft no contienen un número de versión en el directorio de framework.
basta con mirar el .NET Framework o cualquier otro producto de Microsoft para el caso. poner una versión como parte del nombre del ensamble suena como una mala idea.
Hay un lugar para esto (y otra información) en la sección de metadatos del conjunto. (AssemblyInfo.cs)
Esta información se puede ver en el Explorador de Windows (cuadro de diálogo de propiedades, barra de estado, información sobre herramientas: todos muestran esta información).
Dado que la versión se puede establecer como una propiedad, ¿no es esto semi redundante?
también me gustaría ir en una extremidad y sugieren MS no tiene un estándar dado un vistazo rápido a sus nombres DLL: user32.dll, tcpmon.dll, winsock.dll, etc.
Estos no son componentes .NET: son win32 nativos y están sujetos a "DLL hell." En .NET, el gac se utiliza para proporcionar control de versiones y permite que las DLL posteriores tengan el mismo nombre físico. – x0n
¡No estoy seguro de que citar 20 años de arqueología de software sea terriblemente relevante! Los nombres de esa época tenían que ser 8.3, lo que tiende a dominar el debate. –
Framework Design Guidelines por Krzysztof Cwalina y Brad Abrams de Microsoft sugiere el montaje nombrar como
<Company>.<Component>.dll
apoyo aún más este (sin utilizar la versión #) debido a que el GAC y las propiedades del archivo DLL se mostrará la versión.
Y, como se dijo, se puede acceder a la versión del ensamblado a través de las propiedades de ensamblado en AssemblyInfo.cs –
Creo que la idea principal de poner un número de versión en el nombre de archivo de una DLL proviene de DLL Hell, donde tener varias versiones de la DLL, todas con el mismo nombre causaron problemas (es decir, qué versión real de una DLL tiene y tiene las funciones requeridas, etc.).
.NET Framework maneja dependencias completamente diferentes en comparación con los archivos DLL de C/C++ que son más tradicionales, es posible tener múltiples versiones de una biblioteca en el GAC, principalmente porque el GAC es una carpeta 'falsa' que enlaces a otros archivos en el sistema de archivos, además de poder tener los ensamblajes incluidos con su instalación ejecutable (misma carpeta de implementación, etc.).
Sé que DevExpress website usa indicadores de versión como parte de los nombres de ensamblado como XtraEditors8.2.dll. Supongo que la razón es que desea poder tener múltiples versiones del ensamblaje ubicadas en el mismo directorio. Por ejemplo, tenemos alrededor de 15 clientes inteligentes que se distribuyen como parte del mismo shell/cliente. Cada cliente inteligente puede tener una versión diferente de los controles DevExpress y, por lo tanto, debemos poder tener XtraEditors7.1.dll y XtraEditors8.2 en el mismo directorio.
Yo diría que si tiene bibliotecas comunes que son dependencias de módulos reutilizables y pueden existir en múltiples versiones 1.0, 1.1, 1.2 etc. entonces sería un argumento válido que los números de versión podrían incluirse en el nombre para evitar colisiones Dado que las bibliotecas comunes no viven en el GAC.
Lo hago por exactamente esa razón. He compartido dll en una unidad de red utilizada por múltiples programas y personas. Si hay un problema en el tiempo de actividad, puedo actualizar un dll y el programa depender de él sin afectar a los usuarios. – PeteT
Microsoft usó un sufijo de 32 para denotar las versiones de DLL de 32 bits para que esas DLL pudieran coexistir con los archivos DLL de 16 bits existentes.
¿Cómo se aumenta el número de compilación automáticamente después de cada compilación? ¿O tengo que abrir manualmente este archivo y cambiar el número máximo, mínimo, de compilación cada vez? –
use y * en lugar de un número y la compilación aumentará automáticamente el valor. 1.1. * –
También podría establecer AssemblyInformationalVersion que termine como el campo VERSIONINFO "ProductVersion". –