debug - Error "Archivo de metadatos '... \ Release \ project.dll' no se pudo encontrar en Visual Studio"



cs0006 could (20)

¿Revisó la configuración del administrador de configuración? En el diálogo de configuración del proyecto, esquina superior derecha.

En algún momento ocurre que entre todas las entradas de la versión entra una entrada de depuración. De ser así, la dependencia automática creada por la grapgh de dependencia de la solución se confunde.

Recientemente comencé a recibir este mensaje al azar:

No se pudo encontrar el archivo de metadatos '... \ Release \ project.dll' en Visual Studio

Tengo una solución con varios proyectos en ella. El modo de compilación actual es Depurar y todas las configuraciones de proyectos están configuradas en Depurar. Pero cuando trato de ejecutar el proyecto principal, a veces me da algunos errores, todos los cuales son "Archivo de metadatos '... \ Release \ projectX.dll' no se pudo encontrar" - y, mira, dice acerca de LIBERACIÓN carpeta, aunque el modo actual es Depurar. ¿Por qué? Traté de buscar una referencia a "Release \ projectX.dll" dentro de todos los archivos de solución, y encontré uno en el archivo ResolveAssemblyReference.cache.

Hice una buena búsqueda a través de Internet y encontré algunas personas con un problema similar, pero no había solución, o al menos no solución de trabajo.

Traté de eliminar las referencias a esos proyectos y leerlos, pero en algún momento empiezo a recibir estos errores nuevamente.

Parece un error. ¿Por qué busca proyectos referenciados en las carpetas de Release cuando siempre uso el modo Debug?

PD. Para aquellos que encontraron este problema: no pude resolverlo de una manera fácil. Desapareció solo después de que reinstalé Windows :(


COMPRUEBA TU CAMINO DEL PROYECTO. No debería tener carácter irregular como coma y espacio

por ejemplo, esta es una ruta incorrecta: d: \ my applications \ Project1

y esta es la verdadera ruta d: \ my_applications \ Project1

El estudio visual no puede construir el proyecto cuando hay un carácter no alfabético y numérico en su camino en el disco y no muestra ningún mensaje para este error.

Además, algunas herramientas de instalación tienen el mismo problema cuando comienzan la instalación y no se pueden extraer.


En mi caso, fue causado por dos cosas (VS.2012):

1) Uno de los proyectos se configuró para AnyCPU en lugar de x86

2) Un proyecto al que se hizo referencia tenía de alguna manera la casilla "Crear" sin marcar.

Verifique su compilación | Configuration Manager para obtener una visión general de lo que se está creando y para qué plataforma. También asegúrate de verificar Debug & Release, ya que pueden tener configuraciones diferentes.


En mi caso, tuve algunos errores en mi código. Visual Studio mostró el error que tenía en lugar de los errores reales, como los errores de sintaxis o los nombres de clase desconocidos. Intente limpiar la solución y crear el proyecto después del proyecto. De esta manera descubrirá los errores reales.

De nuevo, esto es solo lo que causa el error para .


Encuentro que esto generalmente se me ocurre cuando todavía tengo una declaración de método en una interfaz, que una clase implementa, pero que luego eliminé y olvidé eliminarla de la interfaz también. Por lo general, solo guardo la solución completa cada 30 minutos y luego simplemente vuelvo a una versión anterior si no puedo encontrar el error.


Este problema se debe a los archivos pdb o CodeContracts, para resolverlo:

1) Limpie su carpeta de salida y reconstruya la solución.

2) Vuelva a configurar CodeContracts o deshabilítelo para la compilación temporal.

Espero que esto ayude.

Atentamente,


He tenido este problema antes y la única forma que he encontrado para resolverlo es ejecutar Clean Solution y luego reiniciar Visual Studio.


La mayoría de los answares dicen que debe eliminar las bibliotecas de su solución, esto es cierto, pero cuando vuelva a agregar las bibliotecas, el error volverá a aparecer. Debe verificar si todas las bibliotecas a las que se hace referencia tienen un .NET framework compatible con .net framework de su solución. Luego arregle todos los errores en su código y reconstruya la solución.


Me parece recordar haber tenido un problema similar hace unos meses. Lo solucioné temporalmente copiando el archivo DLL al que se hace referencia en la carpeta Release, satisfaciendo así las expectativas de Visual Studio. Más tarde, descubrí la referencia a la DLL de lanzamiento en mi código actual. Intente hacer una búsqueda a través del proyecto completo para \ release \ project.dll.

Además, he notado que los proyectos de prueba de unidad de Visual Studio a veces ponen un atributo "DeploymentItem" en cada uno de los métodos de prueba que apuntan a su DLL de destino, y si cambia entre Debug y Release, Visual Studio puede confundirse si el DLL ya no es en la ubicación esperada. En mi experiencia, estos atributos se pueden eliminar de forma segura si no los colocaste allí como parte de un escenario de "implementación única".


Para mí, esto fue causado por el objetivo de compilación que se reescribió para no generar el dll. Eliminar esto para volver al objetivo de compilación predeterminado solucionó el problema.


Parece suceder cuando pagas una solución con múltiples proyectos que tienen referencias entre ellos, y no la has creado antes. Si tiene referencias directamente a los dlls, en lugar de hacer referencia al proyecto, obtendrá este mensaje. Siempre debe usar la pestaña Proyectos en el cuadro de diálogo Agregar referencia para agregar una referencia a un proyecto en la misma solución. De esta forma, VS puede saber el orden correcto en el que se construye la solución


Recientemente nos encontramos con este problema después de actualizar a Office 2010 desde Office 2007: tuvimos que cambiar manualmente las referencias de nuestro proyecto a la versión 14 de Office Interops que usamos en algunos proyectos.

Espero que eso nos ayude, nos llevó unos días descubrirlo.


Tenemos ese problema con bastante frecuencia, pero solo con referencias a proyectos C ++ / CLI de proyectos C #. Obviamente es un error en VS que Microsoft decidió no corregir porque es "demasiado complejo" y prometieron una revisión del sistema de compilación C ++ que ahora está destinado a VS 2010.

Eso fue hace un tiempo, y tal vez la solución incluso entró en VS 2008, ya no la seguí. Sin embargo, nuestra solución típica fue

  • cambiar configuración
  • reiniciar Visual Studio
  • construir solución

Terminé borrando mis referencias (las había agregado correctamente usando la pestaña de proyectos, y solían crear muy bien), editando a mano mis archivos .csproj y eliminando las entradas extrañas que no pertenecían, y estableciendo mis salidas para depuración y release, x86 y x64 y cualquier CPU a todos sea "\ bin" - Lo construí una vez, luego volví a agregar la referencia (nuevamente, usando la pestaña de proyectos), y todo comenzó a funcionar nuevamente para mí. No tuvo que reiniciar Visual Studio en absoluto.


Tuve el mismo problema hoy.

Mi aplicación, una aplicación de Windows Forms, tuvo accidentalmente una referencia a sí misma. Extraño.

Una vez eliminado, el error desapareció.

La referencia se agregó cada vez que arrastré un control de usuario, ubicado en el proyecto de Windows Forms, a un formulario.


Tuve este problema y fue debido a un método no válido en la biblioteca ofensiva (dll) que no devolvió un valor, por ejemplo

public bool DoSomething()
{
   //I never bothered putting code here....

}

Cuando commé esto, compilé todo :)


Tuve exactamente el mismo problema. Gran solución de estudio visual con más de 50 proyectos.

Todas las referencias fueron agregadas como proyectos. El orden de compilación del proyecto fue correcto (haga clic derecho en el proyecto y seleccione el orden de compilación).

Sin embargo, al construir algunos de los proyectos de mayor nivel, no se construyó el proyecto "raíz" del que dependían.

El problema fue que estos proyectos no fueron seleccionados para construir bajo la configuración actual (no sé cómo sucedió esto).

Para comprobar esto, seleccione "Configuration Manager" (menú Generar) e compruebe si los proyectos problemáticos están configurados para compilar.


Vuelva a abrir Visual Studio como administrador.


Yo tuve el mismo problema. La eliminación manual y la adición de dlls no ayudaron. ClassLibraries no compiló para todos los proyectos y faltaba en la carpeta ... \ bin \ Debug para el proyecto [porque limpié la solución por error]. Como la biblioteca de clases no compilaba eso significa que puede haber algunos errores en alguno de esos subproyectos .

Solución: como mis dlls estaban allí para la carpeta ... \ bin \ Release , intenté reconstruir en modo Release y encontré un error en una línea en uno de los subproyectos. La solución del error y la reconstrucción de la solución eliminaron el error de compilación.


Yo tuve el mismo problema. Noté que mi contexto de db (EF4) que estaba ubicado en el dll del proyecto no fue reconocido por alguna razón. Lo eliminé y creé otro en su lugar. y eso lo resolvió para mí.





resolveassemblyreference