Referencias y versiones de Visual Studio: ¿cómo funciona?

Question

Tenemos varias librerías comunes. Lo ideal es que queremos que todos ellos utilizan la última versión de un archivo DLL aunque se han compilado con una versión diferente mayores (suponiendo que la última versión es compatible hacia atrás)

por ejemplo tenemos:

DLL Proyecto
Común DLLs
registro DLL
acceso a la base de datos DLL

Proyecto y referencia v2 de la base de datos DLL controles comunes. Sin embargo, el registro hace referencia a v1.

Si se hace referencia a versiones diferentes en componentes diferentes, ¿cómo selecciona VS cuál usar?
¿Tenemos que volver a compilar v1 dll para usar la última base de datos (v2) o podemos hacer que esto se recoja automáticamente?
¿Es posible forzar el uso de una versión en particular?

Gracias,

Alex

Answer 1

Por defecto, para DLL versionados creo VS forzará una coincidencia exacta. Sin embargo, si observa las propiedades de la referencia, encontrará una propiedad llamada "Versión específica". Ponlo en "falso" y coincidirá con las versiones posteriores.

No tengo la versión completa de VS conmigo para encontrar un enlace de MSDN apropiado, desafortunadamente.

Además, puede usar el elemento assemblyBinding en app.config.

Answer 2

Si tiene la fuente, podría utilizar las referencias del proyecto en lugar de las referencias dll. De esa manera siempre obtendrías lo último.

Answer 3

me encontré con este sitio que tiene un par de sugerencias: http://blog.fredrikhaglund.se/blog/2008/02/23/get-control-over-your-assembly-dependencies/

para obtener una versión específica al parecer, tiene que editar web.config o app.config?

"Finalmente, eche un vistazo a su archivo csproj usando el bloc de notas (o descargue el proyecto en Visual Studio para poder abrirlo como texto). Cuando agrega referencias usando Visual Studio, obtendrá una referencia de ensamblado con ambas versiones número y clave pública, y esto puede ocasionarle problemas cuando actualiza un ensamblaje de proveedor a una versión más nueva ".
http://blog.fredrikhaglund.se/blog/2008/02/23/get-control-over-your-assembly-dependencies/

Answer 4

En realidad, hay dos situaciones aquí: usar nombres fuertes/GAC, o no usar nombres fuertes.

Si usa nombres fuertes e instala los componentes en el GAC, entonces .Net querrá usar la versión del componente al que el cliente hacía referencia cuando se compiló. Por lo tanto, en su ejemplo, sería bastante posible que Project hiciera referencia a la base de datos V2, mientras que Logging hizo referencia a la base de datos V1, porque las DLL se pueden almacenar en paralelo en el GAC. Por lo tanto, si realmente desea que Logging use V2 en lugar de V1, deberá modificar los archivos de configuración para decir que "una referencia a V1 debe apuntar a V2". Hay diferentes lugares para hacer esto: archivo de aplicación, archivo de máquina, etc.

Si no está usando nombres fuertes, entonces.Net usará de manera predeterminada la versión de la DLL que está en la misma carpeta que el cliente. Supongamos que despliega Project, CommonControls y Logging en la misma carpeta que la base de datos V2. Entonces, incluso si el registro fue construido contra la base de datos V1, intentará usar el componente en la misma carpeta, es decir, la base de datos V2. Siempre que V2 pueda proporcionar las mismas clases y métodos públicos que Logging desea utilizar, funcionará correctamente.

En mi entorno, donde todas nuestras aplicaciones son internas, no utilizamos el GAC. Simplemente implementamos todos los archivos que la aplicación necesita en una sola carpeta. Cuando tiene muchos componentes comunes, sería una pesadilla mantener sincronizados los archivos de configuración.

Esto es todo muy diferente de COM, donde todas las aplicaciones recogieron la copia registrada actualmente de la DLL (suponiendo que V1 y V2 eran compatibles con binarios).