c# - namespace - Nombres de ensambles y versiones

interface naming convention c# (3)

Dar nombres diferentes a las diferentes versiones de ensamblaje es la manera más fácil y seguramente funciona.

Si su ensamblado (commonutils.dll) tiene un nombre seguro (es decir, firmado), puede pensar en instalarlo en el GAC (caché de ensamblaje global: puede instalar diferentes versiones del mismo ensamblado una al lado de la otra en el GAC), por lo tanto, la aplicación de llamada obtiene automáticamente la versión correcta de allí porque los tipos de .NET incluyen información de la versión del ensamblado.

En su proyecto VS hace referencia a la versión correcta de la biblioteca, pero no la despliega en la carpeta de la aplicación; lo instala en el GAC (durante la configuración de la aplicación).

¿Qué se considera una mejor práctica cuando se trata de montajes y lanzamientos?

Me gustaría poder hacer referencia a varias versiones de la misma biblioteca: la solución contiene múltiples proyectos que dependen de las diferentes versiones de una biblioteca commonutils.dll que creamos nosotros mismos.

Como todas las dependencias se copian en bin / debug o bin / release, solo puede existir una sola copia de commonutils.dll a pesar de que cada uno de los archivos DLL tiene números de versión de ensamblaje diferentes.

¿Debo incluir números de versión en el nombre del ensamblado para poder hacer referencia a múltiples versiones de una biblioteca o hay alguna otra manera?

Los ensamblados pueden coexistir en el GAC (Global Assembly Cache) incluso si tienen el mismo nombre dado que la versión es diferente. Así es como funcionan los ensamblados .NET Framework. Se debe firmar un requisito que debe cumplirse para que una asamblea pueda registrarse en el GAC.

Agregar números de versión al nombre de la Asamblea simplemente vence el propósito general del ecosistema de ensamblaje y es engorroso en mi humilde opinión. Para saber qué versión de un ensamblaje dado, acabo de abrir la ventana Propiedades y verificar la versión.

Esto es por lo que he estado viviendo:

Depende de lo que planea usar los archivos DLL para. Los clasifico en dos grupos principales:

Asambleas sin salida. Estos son archivos EXE y archivos DLL de los que realmente no tiene previsto hacer referencia desde ningún lugar. Simplemente déjelos de nombre y asegúrese de tener los números de versión que publica etiquetados en control de fuente, para que pueda deshacerlos siempre.
Asambleas referenciadas Nombre fuerte estos para que pueda tener múltiples versiones de referencia por otros ensamblados. Use el nombre completo para hacer referencia a ellos (Assembly.Load). Guarde una copia de la última y mejor versión en un lugar donde otro código pueda hacer referencia a ella.

A continuación, tiene la opción de copiar local o no sus referencias. Básicamente, la compensación se reduce a: ¿desea tomar parches / actualizaciones de sus referencias? Puede tener un valor positivo al obtener nueva funcionalidad, pero, por otro lado, podría haber cambios bruscos. La decisión aquí, creo, debe tomarse caso por caso.

Mientras desarrollas en Visual Studio, de forma predeterminada tomarás la versión más reciente para compilar , pero una vez compilado, el conjunto de referencia requerirá la versión específica con la que se compiló.

Su última decisión es copiar local o no. Básicamente, si ya tiene un mecanismo implementado para implementar el ensamblado al que se hace referencia, configúrelo como falso.

Si está planificando un gran sistema de gestión de versiones, probablemente deba poner mucho más cuidado y pensar en esto. Para mí (pequeña tienda, dos personas), esto funciona bien. Sabemos lo que está pasando y no nos sentimos restringidos por tener que hacer las cosas de una manera que no tiene sentido.

Una vez que alcances el tiempo de ejecución, Assembly.Load lo que quieras en el dominio de la aplicación . Luego, puede usar Assembly.GetType para llegar al tipo que desee. Si tiene un tipo que está presente en varios ensamblados cargados (como en varias versiones del mismo proyecto), puede obtener una excepción AmbiguousMatchException . Para resolver eso, necesitará obtener el tipo de una instancia de una variable de ensamblaje, no del método estático Assembly.GetType.