.net - una - no se puede agregar referencia.dll c#

Proyecto Referencias DLL version hell (11)

Estamos teniendo problemas para que Visual Studio recopile la última versión de una DLL de uno de nuestros proyectos.

Tenemos varios proyectos de bibliotecas de clases (por ejemplo, BusinessLogic, ReportData) y varios servicios web, cada uno tiene una referencia a una DLL de conectividad que hemos escrito (esta referencia a la DLL de conectividad es el problema).

Siempre apuntamos referencias a la DLL en la carpeta bin / debug, (que es donde siempre compilamos para cualquier proyecto dado) y todas las referencias de DLL personalizadas tienen CopyLocal = True y SpecificVersion = False

ReportData tiene una referencia a la lógica empresarial (que también tiene una referencia a la conectividad: no veo por qué esto debería causar un problema, pero creo que vale la pena mencionarlo)

Lo extraño es que cuando hace clic en "Agregar referencia" y navega a Conectividad / bin / depuración - pasa el mouse sobre el archivo DLL, se muestra la versión correcta (la última) (la versión y la versión del archivo siempre se incrementan juntas), pero Cuando haces clic en Aceptar, se extrae un número de versión anterior. Incluso cuando busco en la carpeta de depuración de proyectos actuales (donde copiar local pondría la DLL después de compilarla) muestra el número de la última versión. - NO DONDE puedo encontrar la versión anterior de la DLL fuera de Visual Studio, pero en las referencias de ese proyecto tiene la versión anterior, aunque la ruta sea correcta.

Estoy en una pérdida en cuanto a dónde podría estar obteniendo las versiones anteriores. O incluso por qué quiere eso.

Este es posiblemente el problema más frustrante que he encontrado.

¿Alguien sabe cómo asegurarse de que la versión más reciente se ejecute (preferiblemente automáticamente o en compilación)?

EDITAR:

Aunque no es exactamente el escenario con el que estoy lidiando, estaba leyendo this artículo y en algún lugar menciona que CLR ignora los números de revisión. Comprensible (aunque esto no ha sido un problema antes, estamos en la revisión 39), así que pensé que actualizaría el número de compilación, pero no funcionó. En un vano intento pensé que actualizaría el número de versión menor y vería si eso hacía alguna diferencia.

No digo que esta sea la respuesta, ya que primero tengo que comprobar algunas cosas, pero a primera vista, parece haber resuelto mi problema ...

Edición adicional: en otras bibliotecas de clase, esto parece haber resuelto el problema, sin embargo, en una aplicación de prueba de Windows, aún se puede extraer una versión anterior a través de :(

Si vuelvo a incrementar el número de versión menor, el mismo problema vuelve y me quedo con la versión incorrecta que se está retirando.

Edición adicional: creé un proyecto completamente nuevo, agregué una referencia y todavía tenía el mismo problema. Esto sugiere que el problema está restringido al proyecto al que estoy haciendo referencia. Ojalá supiera por qué!

¿Alguien ha tenido este problema antes y sabe cómo solucionarlo?

¡AYUDA!

¿Has intentado agregar la referencia como referencia de proyecto? Es decir, Agregar referencia ... -> pestaña Proyectos -> Seleccione su proyecto

Echa un vistazo a estas cosas:

si la aplicación web del host y su referencia hacen referencia a una dll problemática. Por ejemplo, digamos que su aplicación web utiliza abc.dll (problemática) y otra dll xyz.dll (es decir, un proyecto de clase que también hace referencia a abc.dll).

En este caso, supongamos que ha actualizado abc.dll de la versión 1 a la versión 2 y que ha vuelto a hacer referencia en su aplicación web. pero durante el proceso de creación, la versión 2 de abc.dll volverá a la versión 1, porque xyz.dll usa la versión 1 y la aplicación web sobrescribe la versión 2 de abc.dll a la versión 1 de abc.dll durante la actualización automática en xyz.dll .

Solución: coloque la versión actualizada de abc.dll versión 2 en la clase de proyecto bin de xyz.dll, también

Esperanza, por encima de los detalles ayudará, buena suerte.

Estamos experimentando un problema muy similar con el WPFToolkit. Acabamos de actualizar a la versión de febrero de 2010 (utilizando el msi del 5 de marzo). "Agregar referencias" muestra los archivos correctos en la ubicación correcta, pero enumera los números de versión anteriores. Sin embargo, los archivos físicos tienen la versión correcta #s. Han desinstalado, eliminado manualmente todas las referencias de WPFToolkit del registro, etc., sin éxito. Debe estar guardando estas cosas en algún lugar, pero aún no hemos podido resolverlo. Perdiendo horas en esto.

Habilite FusionLog y después de que la DLL no se cargue, abra el archivo con el nombre de la DLL en la carpeta C: / FusionLog / Default / devenv.exe. Esto mostrará la ruta desde donde se cargó realmente la DLL.

En mi caso, una versión antigua había aparecido misteriosamente en

C: / Archivos de programa / Microsoft Visual Studio 10 / Common7 / IDE!

Para evitar que esto vuelva a suceder, agregué una regla de seguridad "Denegar escritura" a Todos en Common7 / IDE.

Hay pocas opciones que puedes probar.

Compile el proyecto y vea en la ventana de resultados para verificar la ruta de montaje desde donde se hace referencia exactamente.
Elimina la carpeta Obj antes de recompilarla.
Cierre y vuelva a abrir Visual Studio, ya que VS tiene un comportamiento extraño para mantener la memoria caché para contener las referencias a DLL.
Si aún ve el problema, use esta herramienta para verificar el ensamblaje de referencia de dónde proviene realmente. Explorador de procesos .

Nosotros (y, como el único desarrollador .NET en nuestro equipo, con eso quiero decir que yo) tuvimos exactamente el mismo problema. Lo rastreé hasta una dll referenciada, que a su vez OTRA VEZ hace referencia a la dll que padece la versión de la versión. Parece que debido a que no estaba actualizando todas las referencias que a su vez hacen referencia a la dll, fue reemplazada por una versión anterior en algún momento durante el proceso de construcción.

Uno de los síntomas que experimenté fue que cuando estoy en el editor de código, la nueva clase que agregué al proyecto al que se hace referencia se colorearía adecuadamente, pero cuando presiono Crear, vuelve a ser negro y aparece un mensaje que dice que la clase sí. no existe (junto con un muy sarcástico "¿Está perdiendo una referencia de ensamblaje?"). Esto me llevó a creer que el problema tiene que ocurrir durante la fase de compilación.

Por lo tanto, sugeriría crear cualquier otro proyecto que apunte a esta DLL y volver a agregar sus referencias también.

Para superar esto, eliminé TODAS las referencias, luego las volví a agregar. No sé por qué esta es la solución.

Es posible que en un proyecto un archivo DLL fuera incorrecto, y es este archivo DLL incorrecto el que realizó Visual Studio y se utilizó.

Edición: Otras veces que se ha producido este error se debe a que se hace referencia a un DDL (A) en el proyecto actual a otro DLL (B). No reconstruir esta otra DLL (B) parece evitar que VS haga referencia a la versión correcta de DLL (A) en el proyecto actual y, por lo tanto, se traslada a una versión anterior de DLL (A).

Síntomas similares: el problema estaba en "Rutas de referencia" en Propiedades del proyecto, Referencia.

Descripción y solución completas aquí: ensamblajes referenciados reemplazados automáticamente por visual studio visual-studio / 22810867 # 22810867

Tuve un problema similar al que se describe aquí, excepto que mi solución al problema tenía que ver con la forma en que estaba compilando el código. Hay una diferencia entre construir, limpiar y reconstruir. En mi caso, solo estaba usando una compilación entre mis cambios y la dll de la solución dependiente no se estaba llevando a cabo con todos los cambios a la otra solución donde se estableció la referencia. Lo resolví utilizando Rebuild, que limpia, compila y vincula todos los archivos de origen, independientemente de si han cambiado o no. Luego, la dll de la primera solución se actualizó y se copió automáticamente a la segunda solución donde se estableció la referencia y se resolvió el problema. Saludos, espero que esto ayude.

Una posible razón es la ruta de referencia. Si hay alguna referencia a la carpeta dll antigua, VS la usará como referencia principal, aunque haya agregado la nueva referencia dll.

Para evitar el infierno de dll, te recomendaría crear una carpeta lib dentro de tu proyecto y colocar todos los ensamblados compartidos en esta carpeta. A continuación, agregue referencias solo desde esta carpeta. De esta manera, su proyecto es autónomo y usted sabe exactamente de dónde está escogiendo las referencias. Si desea actualizar algún ensamblaje con una versión más nueva, cópielo en la carpeta lib y reconstruya su proyecto.

También asegúrese de no colocar los ensamblajes referenciados en el GAC, ya que podrían recogerse primero.