No se pudo encontrar el archivo de metadatos ‘.dll’

Estoy trabajando en un proyecto WPF, C # 3.0, y me sale este error:

Error 1 Metadata file 'WORK=- \Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug \BusinessLogicLayer.dll' could not be found C:\-=WORK=- \Tools \VersionManagementSystem\VersionManagementSystem\CSC VersionManagementSystem 

Así es como hago referencia a mis controles de usuario:

 xmlns:vms="clr-namespace:VersionManagementSystem"  

Sucede después de cada comstackción fallida. La única forma en que puedo obtener la solución para comstackr es comentar todos mis controles de usuario y volver a comstackr el proyecto, y luego descomentar los controles de usuario y todo está bien.

He verificado las órdenes de comstackción y las configuraciones de dependencias.

Como puede ver, parece haber truncado la ruta absoluta del archivo DLL … He leído que hay un error con la longitud. ¿Es esto un posible problema?

Es muy molesto y tiene que comentar, construir y comentar, la construcción se está volviendo extremadamente tediosa.

Acabo de tener el mismo problema. Visual Studio no está creando el proyecto al que se hace referencia.

  1. Haga clic derecho en la solución y haga clic en Propiedades.
  2. Haga clic en Configuración a la izquierda.
  3. Asegúrese de marcar la checkbox debajo de “Crear” para el proyecto que no puede encontrar. Si ya está marcado, desmarque, presione Aplicar y marque las casillas nuevamente.

Esto todavía puede suceder en versiones más nuevas de Visual Studio (acabo de suceder en Visual Studio 2013):

Otra cosa que debe intentar es cerrar Visual Studio y eliminar el archivo .suo que está al lado del archivo .sln . (Se volverá a generar la próxima vez que Save all (o salga de Visual Studio)).

He tenido este problema al agregar nuevos proyectos a la solución en otra máquina y luego incorporar las revisiones, pero el archivo .suo puede corromperse también en otros casos y dar lugar a un comportamiento muy extraño de Visual Studio, por lo que eliminarlo es uno de las cosas que siempre bash

Tenga en cuenta que eliminar el archivo .suo restablecerá los proyectos de inicio de la solución.

Más sobre el archivo .suo está aquí .

La respuesta sugerida no funcionó para mí. El error es un señuelo para otro problema.

Descubrí que estaba apuntando a una versión ligeramente diferente de .NET y el comstackdor lo marcó como una advertencia, pero estaba causando fallas en la construcción. Esto debería haberse marcado como un error y no como una advertencia.

Bueno, mi respuesta no es solo el resumen de todas las soluciones, sino que ofrece más que eso.

Sección 1):

En soluciones generales:

Tuve cuatro errores de este tipo (no se pudo encontrar el archivo de metadatos) junto con un error que decía ‘El archivo de origen no se pudo abrir (‘ Error no especificado ‘)’.

Traté de deshacerme del error “no se pudo encontrar el archivo de metadatos”. Para eso, leí muchas publicaciones, blogs, etc. y encontré que estas soluciones pueden ser efectivas (resumiéndolas aquí):

  1. Reinicie Visual Studio e intente construir nuevamente.

  2. Ve a ‘Solution Explorer’ . Haga clic derecho en la solución. Ir a Propiedades Vaya a ‘Administrador de configuración’ . Compruebe si las casillas de verificación debajo de ‘Build’ están marcadas o no. Si alguno o todos están desactivados, compruébalos y vuelva a intentar comstackr.

  3. Si la (s) solución (es) anterior (es) no funcionan, siga la secuencia mencionada en el paso 2 anterior, e incluso si todas las casillas de verificación están marcadas, desmárquelas, vuelva a verificar e intente comstackr de nuevo.

  4. Orden de comstackción y dependencias del proyecto:

    Ve a ‘Solution Explorer’ . Haga clic derecho en la solución. Vaya a ‘Dependencias del proyecto …’ . Verá dos tabs: ‘Dependencias’ y ‘Orden de comstackción’ . Este orden de comstackción es el que construye la solución. Compruebe las dependencias del proyecto y el orden de comstackción para verificar si algún proyecto (digamos ‘proyecto1’) que depende de otro (digamos ‘proyecto2’) está tratando de comstackr antes que ese (proyecto2). Esta podría ser la causa del error.

  5. Compruebe la ruta del .dll perdido:

    Compruebe la ruta del .dll faltante. Si la ruta contiene espacio o cualquier otro carácter de ruta no válida, quítelo e intente construir nuevamente.

    Si esta es la causa, entonces ajusta el orden de comstackción.


Sección 2):

Mi caso particular:

Intenté todos los pasos anteriores con varias combinaciones y permutaciones al reiniciar Visual Studio varias veces. Pero, no me ayudó.

Entonces, decidí deshacerme de otro error que me encontraba (‘El archivo de origen no se pudo abrir (‘ Error no especificado ‘)’).

Me encontré con una publicación de blog: el archivo de origen de error de TFS no se pudo abrir (‘Error no especificado’)

Intenté los pasos mencionados en esa publicación de blog y me deshice del error “El archivo de origen no se pudo abrir” (“Error no especificado”) y, sorprendentemente, me deshice de otros errores (no se pudo encontrar el archivo de metadatos) como bien.


Seccion 3):

Moraleja de la historia:

Pruebe todas las soluciones mencionadas en la sección (1) anterior (y cualquier otra solución) para deshacerse del error. Si nada funciona, según el blog mencionado en la sección (2) anterior, elimine las entradas de todos los archivos fuente que ya no están presentes en el control de fuente y el sistema de archivos de su archivo .csproj .

En mi caso, fue causado por una versión de .NET Framework no coincidente.

Un proyecto fue 3.5 y el otro proyecto de referencia 4.6.1.

¡El cierre y la reapertura de Visual Studio 2013 funcionó para mí!

Bueno, nada en las respuestas anteriores funcionó para mí, así que me hizo pensar en por qué estoy haciendo clic y esperando cuando como desarrolladores realmente deberíamos tratar de entender qué está pasando aquí.

Me pareció obvio que esta referencia incorrecta del archivo de metadatos debe mantenerse en algún lugar.

Una búsqueda rápida del archivo .csproj mostró las líneas culpables. Tenía una sección llamada que parecía estar colgada en el antiguo y incorrecto filepath.

   {5b0a347e-cd9a-4746-a3b6-99d6d010a6c2} Beeyp.Entities  ... 

Entonces una solución simple realmente:

  1. Haga una copia de seguridad de su archivo .csproj.
  2. Busque las rutas incorrectas en el archivo .csproj y cambie el nombre apropiadamente.

Por favor, asegúrese de hacer una copia de seguridad de su anterior .csproj antes de manipularlo .

Obtuve el mismo error “No se pudo encontrar el archivo de metadatos ‘.dll’, y probé varias cosas descritas anteriormente, pero el motivo del error fue que estaba haciendo referencia al archivo DLL de terceros que apuntaba a una versión .NET más alta que mi proyecto tiene como objective la versión .NET. Entonces la solución fue cambiar el marco meta de mi proyecto.

También conocí este problema. En primer lugar, debe comstackr manualmente su proyecto DLL, haciendo clic con el botón derecho en Build. Entonces funcionará.

En mi caso, tengo mi directorio instalado de forma equivocada.

Si su ruta de solución es algo así como “Mi proyecto% 2c Muy popular% 2c Prueba unitaria% 2c Software y Hardware.zip”, no puede resolver el archivo de metadatos, quizás deberíamos evitar algunas palabras inválidas como% 2c.

Cambiar el nombre de la ruta al nombre normal resolvió mi problema.

Agregué un nuevo proyecto a mi solución y comencé a recibir esto.

¿La razón? El proyecto que introduje tenía como objective un .NET framework diferente (4.6 y mis otros dos eran 4.5.2).

También me estaba tirando de los pelos con este problema, pero después de probar las respuestas anteriores, lo único que funcionó para mí fue abrir cada proyecto en mi solución 1 por 1 y comstackrlos individualmente.

Luego cerré Visual Studio 2013, volví a abrir mi solución y compiló bien.

Es extraño, porque si hacía clic en cada proyecto en mi Explorador de soluciones y traté de comstackrlos de esa manera, todos fallaban. Tuve que abrirlos solos en sus propias soluciones.

Para mí ocurrió cuando incluí un nuevo proyecto en una solución.

Visual Studio selecciona automáticamente .NET framework 4.5.

Cambié a la versión .NET 4.5.2 como las otras bibliotecas, y funcionó.

Para mí, estaba tratando de encontrar una DLL en una ruta que solía contener el Proyecto, pero la habíamos movido a un nuevo directorio. La Solución tenía la ruta correcta al Proyecto, pero Visual Studio de alguna manera siguió buscando en la ubicación anterior.

Solución: Cambie el nombre de cada problema Proyecto – simplemente agregue un carácter o lo que sea – luego cambie el nombre a su nombre original.

Esto debe restablecer algún tipo de memoria caché global en Visual Studio, porque esto borra tanto este problema como otros similares, mientras que cosas como Clean no lo hacen.

Para mí, los siguientes pasos funcionaron:

  • Encuentra el proyecto que no está construyendo
  • Eliminar / agregar referencias a proyectos dentro de la solución.

Mi instancia del problema fue causada por un proyecto común que tenía un nombre de clase duplicado (con un nombre de archivo diferente). Es extraño que Visual Studio no haya podido detectar eso y en su lugar haya explotado el proceso de comstackción.

Obtuve este problema en Visual Studio 2012 en una solución que tenía muchos proyectos. Reconstruir manualmente cada proyecto en la solución en el mismo orden que el Orden de comstackción del proyecto (hacer clic con el botón derecho y reconstruir en el Explorador de soluciones) lo solucionó.

Eventualmente llegué a uno que me dio un error de comstackción. Solucioné el error y la solución se comstackría correctamente después de eso.

En mi caso, el problema fue causado por un simple error de comstackción,

error CS0067: el evento ‘XYZ’ nunca se usa

que, por cualquier razón, no apareció en la ventana de error.

Debido a eso, el sistema de comstackción de Visual Studio pareció pasar por alto el error e intentó crear proyectos dependientes, que a su vez fallaron con el molesto mensaje de metadatos.

La recomendación es -por estúpida que parezca-:

¡Primero mira tu ventana de salida !

Me tomó media hora antes de que esta idea me golpeara …

En mi caso, el problema era que había borrado manualmente un archivo no comstackdo que estaba marcado como “perdido”. Una vez que eliminé la referencia al archivo que faltaba y volví a comstackr, todo estaba bien.

Tuve el mismo problema. En mi caso, el proyecto seguiría construyendo en modo de lanzamiento y fue justo cuando traté de construir en la depuración que falló.

Lo que terminé haciendo para solucionar el problema fue simplemente copiar todos los dlls (y otros archivos de mi carpeta de lanzamiento) en mi carpeta de depuración. Después de hacer esto para cada proyecto, los errores desaparecieron.

Si tiene un espacio en el nombre de su solución, esto también causará el problema. Eliminar el espacio del nombre de su solución, para que path no contenga% 20 lo resolverá.

Simplemente señalando lo descaradamente obvio: si no tiene activada la opción “Mostrar ventana de resultados cuando se inicia la comstackción”, asegúrese de estar notando si su comstackción está fallando (error pequeño de “comstackción fallida” en la parte inferior izquierda) !!!!

Tuve este error cuando intentaba publicar una aplicación web. Resultó que una de las propiedades de clase estaba envuelta en

 #if DEBUG public int SomeProperty { get; set; } #endif 

pero el uso de la propiedad no fue así. La publicación se realizó en la configuración de lanzamiento sin el símbolo DEBUG , obviamente.

Volviendo a esto unos años más tarde, este problema está más que probablemente relacionado con el límite máximo de ruta de Windows:

Nombrar archivos, rutas y espacios de nombres , limitación máxima de la longitud de la ruta

Estoy ejecutando Visual Studio 2013.

Parece que las dependencias de comstackción fueron incorrectas. Eliminar los archivos * .suo solucionó los problemas que tenía.

Para mi caso, era que había comentado clases en un espacio de nombres específico (vacío):

 namespace XYZW { // Class code } 

Cuando eliminé el código del espacio de nombres y los comandos de importación (uso) de él, solucionó el problema.

En la comstackción, también decía: junto con el archivo DLL faltante del proyecto:

error CS0234: El tipo o el nombre del espacio de nombres ‘W’ no existe en el espacio de nombres ‘XYZ’ (¿falta una referencia de ensamblado?)

Yo también tuve el mismo error. Se esconde como en el camino de abajo. La ruta a la que me refería para el archivo DLL es como “D: \ Assemblies Folder \ Assembly1.dll”.

Pero la ruta original a la que se refería la asamblea era “D: \ Assemblies% 20Folder \ Assembly1.dll”.

Debido a esta variación del nombre de ruta, el ensamblado no se pudo recuperar de su ruta original y, por lo tanto, arroja el error “Metadata no encontrada”.

La solución está en Stack Overflow question ¿Cómo puedo reemplazar todos los espacios con% 20 en C #? .

Este error puede aparecer si usa ensamblajes falsos. La eliminación de falsificaciones conduce a la construcción exitosa del proyecto.

Recibí este error después de abrir un proyecto en el que se hizo referencia a Entity Framework, por lo que eliminé dichas referencias y reinstalé Entity Framework versión 6.0.0.0 a través del administrador de acket de esta manera:

 install-package entityframework -version 6.0.0.0 

El error seguía mostrándose, así que pensé que esas referencias estaban ahí porque había una versión anterior de Entity Framework supuestamente “preinstalada” en el proyecto, pero en realidad no funcionaba.

Así que fui al archivo packages.config y noté que había otra referencia:

  ****   

Luego eliminé la línea, limpié y reconstruí el proyecto y la solución del contenedor, y finalmente funcionó.

Tuve un problema similar cuando descompilé una biblioteca muy antigua, que se implementó en un entorno de producción, pero se perdió el código fuente.

Tomé .dll, descompilé y generé proyectos y soluciones. No pude construir la solución debido a varios errores de este tipo.

Las sugerencias en respuestas anteriores no ayudaron, pero después de un tiempo noté que faltaban referencias en algunos proyectos a varios ensamblajes como System.dll.

Supongamos que el proyecto A depende del proyecto B. No se hizo referencia a System.dll en el proyecto B, pero el error después de la comstackción fue como “Archivo de metadatos ‘B.dll’ no se pudo encontrar”.

No se produjo ningún error al omitir System.dll en el proyecto B.

Agregar referencia en bibliotecas como System.dll en el proyecto B resolvió el problema. (System.Data, System.DirectoryServices, etc.)