programming practices net namespace microsoft hungarian guidelines convenciones coding code best and .net naming

.net - practices - interface naming convention c#



¿Los nombres de ensamblados de.NET deberían incluir un número de versión? (9)

Actualmente tenemos un acalorado debate interno sobre si el nombre 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?


Dado que la versión se puede establecer como una propiedad, ¿no es esto semi redundante?

También me iría en una extremidad y sugiero que MS no tiene un estándar dado un rápido vistazo a sus nombres de DLL: user32.dll, tcpmon.dll, winsock.dll, etc.


Esto es para lo que es el archivo Properties / AssemblyInfo.cs.

Hay dos versiones dentro de ese archivo, la versión del archivo y la versión del ensamblado:

[assembly: AssemblyVersion("1.1.0.256"] [assembly: AssemblyFileVersion("1.1.0.256")]

Una vez que estén configurados, puede usarlos para rastrear las versiones de sus 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 usará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.


La información de la versión puede estar contenida en el archivo assemblyInfo y luego puede consultarse 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 ver de un vistazo qué es. Los nombres dll de Microsoft no contienen un número de versión en el directorio de framework.


No estoy al tanto de nada autoritario, pero me parece que usar un nombre consistente 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?


solo mire 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 de la asamblea. (AssemblyInfo.cs)

Esta información se puede ver en el Explorador de Windows (diálogo de propiedades, barra de estado, información sobre herramientas: todos muestran esta información).



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 múltiples versiones de la DLL, todas con el mismo nombre causaron problemas (es decir, qué versión real de una DLL tienes 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 se vincula a otros archivos en el sistema de archivos, además de poder tener los ensamblados incluidos con la instalación ejecutable (misma carpeta de implementación, etc.).


Sé que DevExpress usa indicadores de versión del sitio 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 librerías 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.


Microsoft usó un sufijo de 32 para denotar versiones de 32 bits DLL para que esas DLL pudieran coexistir con los archivos DLL de 16 bits existentes.