it-swarm-es.tech

No se encontró el archivo de metadatos '.dll'

Estoy trabajando en un proyecto WPF, C # 3.0, y recibo 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 me refiero a mis controles de usuario:

xmlns:vms="clr-namespace:VersionManagementSystem"
<vms:SignOffProjectListing Margin="5"/>

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

He comprobado las órdenes de compilació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 en la longitud. ¿Es este un problema posible?

Es muy molesto y tener que comentar, compilar y no comentar, la compilación se está volviendo extremadamente agotadora.

573
Oliver

Acabo de tener el mismo problema. Visual Studio no está construyendo 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 que la casilla de verificación debajo de "Generar" para el proyecto que no puede encontrar esté marcada. Si ya está marcado, desmarque, pulse Aplicar y marque las casillas nuevamente.
  4. (Opcional) Debía hacerlo para los modos de Liberación y Depuración en las propiedades de la solución.
726
Matt_Bro

Esto todavía puede suceder en las versiones más nuevas de Visual Studio (acabo de hacerlo 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 colocar las revisiones, pero el archivo .suo también puede corromperse en otros casos y provocar un comportamiento muy extraño de Visual Studio, por lo que eliminarlo es uno de Las cosas que siempre trato.

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

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

195
corvuscorax

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 esto fue marcado como una advertencia por el compilador, pero estaba causando que la construcción fallara. Esto debería haberse marcado como un error y no como una advertencia.

134
jordan koskei

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

Sección (1):

En general soluciones:

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

Intenté 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 de nuevo.

  2. Vaya a 'Explorador de soluciones' . Haga clic derecho en la solución. Ir a Propiedades . Vaya a 'Administrador de configuración' . Verifique si las casillas de verificación en 'Construir' están marcadas o no. Si alguno o todos están desactivados, entonces verifíquelos e intente construir nuevamente.

  3. Si la (s) solución (es) anterior (es) no funcionan, entonces siga la secuencia mencionada en el paso 2 anterior, e incluso si todas las casillas están marcadas, desmarque, vuelva a marcar e intente compilar nuevamente.

  4. Dependencias de orden de construcción y proyecto:

    Vaya a 'Explorador de soluciones' . Haga clic derecho en la solución. Vaya a 'Dependencias del proyecto ...' . Verá dos pestañas: 'Dependencias' y 'Orden de compilación' . Este orden de compilación es aquel en el que se construye la solución. Verifique las dependencias del proyecto y el orden de compilación para verificar si algún proyecto (por ejemplo, 'project1') que depende de otro (por ejemplo, 'project2') está intentando construir antes de ese proyecto (project2). Esto podría ser la causa del error.

  5. Verifique la ruta del archivo .dll faltante:

    Compruebe la ruta de acceso de la .dll que falta. Si la ruta contiene espacio o cualquier otro carácter de ruta no válido, elimínelo e intente construir nuevamente.

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


Sección (2):

Mi caso particular:

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

Entonces, decidí deshacerme de otro error que estaba encontrando ('El archivo de origen no se pudo abrir (' Error no especificado ')').

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

Intenté los pasos mencionados en esa publicación del blog, y eliminé el error 'El archivo de origen no pudo abrirse (' Error no especificado ')' y, sorprendentemente, eliminé otros errores (' No se pudo encontrar el archivo de metadatos ') también.


Sección (3):

Moraleja de la historia:

Pruebe todas las soluciones como se menciona 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 de origen que ya no están presentes en el control de origen y el sistema de archivos de su archivo .csproj.

90
Vikram

En mi caso, fue causado por una falta de coincidencia de la versión de .NET Framework.

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

34
Eric Schneider

¡Cerrar y reabrir Visual Studio 2013 me funcionó!

23
Roffers

Bueno, nada en las respuestas anteriores funcionó para mí, así que me puse a pensar por qué hago clic y espero cuándo, como desarrolladores, debemos tratar de entender qué está pasando aquí.

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

Una búsqueda rápida del archivo .csproj mostró las líneas culpables. Tuve una sección llamada <itemGroup> que parecía estar colgada en la antigua ruta de archivo incorrecta.

<ItemGroup>
    <ProjectReference Include="..\..\..\MySiteOld\MySite.Entities\MySite.Entities.csproj">
        <Project>{5b0a347e-cd9a-4746-a3b6-99d6d010a6c2}</Project>
        <Name>Beeyp.Entities</Name>
    </ProjectReference>
...

Así que una solución simple realmente:

  1. Copia de seguridad de su archivo .csproj.
  2. Busque las rutas de acceso incorrectas en el archivo .csproj y cámbielas apropiadamente.

Por favor asegúrese de hacer una copia de seguridad de su antiguo .csproj antes de manipular .

16
Alex Stephens

También me encontré con este problema. En primer lugar, debe crear manualmente su DLL proyecto, haciendo clic con el botón derecho en Construir. Entonces funcionará.

14
user1678541

Recibí el mismo error "No se pudo encontrar el archivo de metadatos '.dll'", e intenté varias cosas descritas anteriormente, pero la razón del error fue que estaba haciendo referencia al archivo de terceros [DLL que era apuntando a una versión .NET más alta que mi proyecto. Así que la solución fue cambiar el marco objetivo de mi proyecto.

13
Mladen Nikolov

En mi caso, tengo mi directorio instalado de manera errónea.

Si la ruta de su solución es algo como "My Project% 2c Very Popular% 2c Unit Testing% 2c Software and Hardware.Zip", no puede resolver el archivo de metadatos, quizás debamos evitar algunas palabras no válidas como% 2c.

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

11
masphei

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

¿La razón? El proyecto que presenté tenía como objetivo un marco .NET diferente (4.6 y mis otros dos eran 4.5.2).

10
Todd Vance

Para mí, ocurrió cuando incluí un nuevo proyecto para 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ó.

9
Andre Mesquita

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

Solución: cambie el nombre de cada proyecto de problema, solo agregue un carácter o lo que sea, luego cambie el nombre a su nombre original.

Esto debe restablecer algún tipo de caché global de algún tipo en Visual Studio, ya que esto soluciona este problema y otros similares, mientras que cosas como Limpiar no lo hacen.

9
Chris Moschini

También me estaba quitando el pelo con este problema, pero después de probar las respuestas anteriores, lo único que me funcionó fue abrir cada proyecto en mi solución 1 por 1 y construirlos individualmente.

Luego cerré Visual Studio 2013, reabrí mi solución y la compilé bien.

Es extraño, porque si hice clic en cada proyecto en mi Explorador de soluciones e intenté compilarlos de esa manera, todos fallaron. Tuve que abrirlos solos en sus propias soluciones.

8
prospector

Para mí los siguientes pasos funcionaron:

  • Encuentra el proyecto que no esta construyendo.
  • Eliminar/agregar referencias a proyectos dentro de la solución.
8
Baglay Vyacheslav

Mi ejemplo del problema fue causado 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 pueda detectar eso y en su lugar simplemente hizo estallar el proceso de compilación.

7
Eric

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

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

7
dan-gph

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

error CS0067: el evento 'XYZ' nunca se usa

eso, por cualquier razón, no se mostró en la ventana de error.

Debido a eso, el sistema de compilación de Visual Studio pareció pasar por alto el error y trató de compilar proyectos dependientes, que a su vez fallaron con el molesto mensaje de metadatos.

La recomendación es, como puede parecer estúpido:

Primer vistazo a su Ventana de salida !

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

6
Heinz Kessler

En mi caso, el problema era que había eliminado manualmente un archivo que no era de compilación y que estaba marcado como "faltante". Una vez que eliminé la referencia al archivo que faltaba ahora y lo volví a compilar, todo estaba bien.

6
David Ford

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

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

6
Oliver

Yo también tuve el mismo error. Se esconde como en el camino de abajo. La ruta a la que hice referencia 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 la ruta, el ensamblaje no se pudo recuperar de su ruta original y, por lo tanto, arroja el error "Metadata no encontrado".

La solución está en la pregunta de desbordamiento de pila¿Cómo reemplazo todos los espacios con% 20 en C #?.

5
Arun Prasad

Me había enfrentado al mismo problema. En mi caso, hice referencia a un proyecto de biblioteca de clases con una versión más alta .Net que mi proyecto y VS no pudo generar el proyecto y generó el mismo error que publicaste.

Simplemente configuré .Net versión de mi proyecto de biblioteca de clases (el que había roto la compilación) idéntico a la versión .Net del proyecto referenciado y el problema resuelto.

5
Code_Worm

Parece un error de este tipo relacionado con el hecho de que Visual Studio no proporciona información correcta sobre un error. El desarrollador ni siquiera entiende la razón de la construcción fallida. Puede ser un error de sintaxis o algo más. En común, para resolver tales problemas, debe encontrar la raíz del problema (por ejemplo, consulte el registro de compilación).

En mi caso, el problema era, de hecho, que la ventana Error List no mostraba ningún error. Pero realmente hubo errores de sintaxis; Encontré estos errores en la ventana Output, y después de corregirlos, el problema se resolvió.

5
burzhuy

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

4
FLCL

Según el mensaje de error, no creo que la ruta del archivo esté truncada. Parece ser simplemente incorrecto. Si estoy leyendo el mensaje correctamente, parece estar buscando el archivo DLL en ...

WORK = -\Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug\BusinessLogicLayer.dll

Este no es un camino válido. ¿Es posible que tenga una definición de macro en el proceso de compilación establecida en un valor no válido?

4
JaredPar

Estoy ejecutando Visual Studio 2013.

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

4
DrBB

En mi caso, fue que comenté las clases en un espacio de nombres específico (vacío):

namespace X.Y.Z.W
{

    // Class code

}

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

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

error CS0234: El tipo o nombre de espacio de nombres 'W' no existe en el espacio de nombres 'X.Y.Z' (¿falta una referencia de ensamblado?)

4

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

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

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

4
Dmitri Trofimov

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

4
Ajaco

Solo señale lo descaradamente obvio: si no tiene habilitada la opción "Mostrar ventana de salida cuando se inicie la compilación", asegúrese de que está notando si su compilación está fallando (error pequeño "falla de compilación" en la parte inferior izquierda)

4
tbone

Recibí este error después de abrir un proyecto en el que se hizo referencia a Entity Framework, así 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 apareciendo, por lo que pensé que esas referencias estaban allí porque había una versión anterior de Entity Framework supuestamente "preinstalada" en el proyecto, pero en realidad no estaba funcionando.

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

<packages>
  **<package id="EntityFramework" version="5.0.0" targetFramework="net45" />**
  <package id="EntityFramework" version="6.0.0" targetFramework="net45" />
</packages>

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

3
CoderRoller

En mi caso, estos errores fueron causados ​​por algún daño en el administrador de paquetes de NuGet. Los subproyectos de la solución no se estaban construyendo, pero no se mostraban errores debido a los errores de metadatos.

Una vez que todos los paquetes de NuGet se corrigieron, el proyecto se podría volver a generar correctamente.

3
Nick

Tuve el mismo problema. En mi caso, el proyecto aún se construiría en el modo de lanzamiento y fue justo cuando intenté construir la depuración cuando falló.

Lo que terminé haciendo para solucionar el problema fue simplemente copiar todos los archivos DLL (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.

3
Jack Fairfield

Eliminar la carpeta packages que contiene NuGet en la carpeta de la solución funcionó para mí. Después de reconstruir todo volvió a funcionar. Marque References en la solución y busque referencias que tengan un triángulo amarillo.

Imagen de ejemplo:

 Enter image description here

3
Ogglas

En mi caso, tuve este error porque, uno de mis proyectos usaba una versión de .NET framework diferente de los otros de la solución. Usé el administrador de paquetes de NuGet para instalar NLog, así que creo que se instaló para la versión .Net de este proyecto.

Probé todas las soluciones de este post, pero ninguna estaba funcionando. Quité NLog, limpié la solución y tridé para compilar: Lo mismo, error CS006.

Fue cuando eliminé todos los archivos en obj\Debug de este proyecto que la solución compiló.

3

Tuve un problema similar cuando descomprimí 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é referencias faltantes en algunos proyectos a varios ensamblajes como System.dll.

Supongamos que hay un proyecto A que depende del proyecto B. No hubo referencia a System.dll en el proyecto B, pero el error después de la compilación fue como "No se pudo encontrar el archivo de metadatos 'B.dll'".

No hubo ningún error sobre la falta de 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.)

3
drfaka

Tuve este problema porque .nuget\NuGet.exe no estaba incluido en mi repositorio. Aunque habilité DownloadNuGetExe en NuGet.targets, informó un error de proxy al intentar descargarlo. Esto causó que el resto de las compilaciones del proyecto fallaran.

3
wtjones

Tuve una clase en 4.6.1 referencia a una interfaz que estaba en 4.6.2 ... actualizar la clase a 462 lo solucionó.

3
Antonin GAVREL

En mi caso, algunos de los proyectos en la solución estaban dirigidos a Cualquier CPU , algunos de ellos a x86. El error de compilación desapareció después de unificar el objetivo de la plataforma en la solución.

3
Tomas Kubes

Como lo señala el usuario @burzhuy, puede ser importante mirar la ventana Output, y no solo la ventana Error List.

En mi caso, estaba trabajando en hacer modificaciones al compilador Roslyn . Sus proyectos de compilación ejecutan una verificación adicional para ver si los campos públicos son consistentes con lo que se ha definido como la interfaz pública del compilador, de lo contrario, produce un error RS0016 o RS0017. Agregué un par de campos públicos, y arreglé el error RS0016 pasando el mouse sobre el error y seleccionando "Agregar a API pública".

Más tarde cambié de opinión y moví los campos públicos a una clase diferente. Por alguna razón, esto produjo el "error de archivo de metadatos", y cuanto más jugueteaba con él, más errores recibía.

Debe encontrar el archivo PublicAPI.Unshipped.txt correcto (en mi caso, estaba en E:\Roslyn\32414\src\Compilers\Core\Portable) y editarlo manualmente para eliminar las líneas que ya no son relevantes.

2
RenniePet

En mi caso personal, no pude agregar una referencia a uno de los proyectos en la solución y esto es lo que me estaba dando el error.

2
Jon D

Mi problema se produjo cuando escribí el código c # 7, pero el proyecto estaba usando una versión anterior para.

2
Abdullah Tahan

En mi caso, fue ReSharper ser estúpido y, aunque mi proyecto apunta a C # 6, se me ofrecieron refactorizaciones para usar funciones solo de C # 7.

Por esta razón terminé cambiando este código,

private DateTime? _joinedDate;
[Column(TypeName = "DateTime2")]
public DateTime JoinedDate
{
    get { return _joinedDate ?? DateTime.Now; }
    set { _joinedDate = value; }
}

en este código:

private DateTime? _joinedDate;
[Column(TypeName = "DateTime2")]
public DateTime JoinedDate
{
    get => _joinedDate ?? DateTime.Now;
    set => _joinedDate = value;
}

Por alguna razón, el compilador y el definidor que usan cuerpos de expresión hicieron que el compilador produjera ese error de metadatos en lugar de un error de sintaxis.

2
Mathieu VIALES

aaaaa y seis años después, durante una actualización a Visual Studio 2015, el mismo problema. Debido a que esta solución en particular no está en esta lista, la estoy agregando.

Dos archivos dll referenciados estaban en la carpeta c:\windows\system32 .... Moverlos a una carpeta que no es del sistema y agregar una referencia a la nueva carpeta lo solucionó finalmente. El resto de los temas fue, de hecho, lo que otros ya han dicho aquí.

2
Serve Laurijssen

La causa del problema puede ser que haya mezclado la adición de referencias a DLL archivos y proyectos en la solución.

Si tienes proyectos A, B y C:

  • A hace referencia a B y C como proyectos en la solución.
  • B hace referencia a C como un archivo DLL (referencia a un archivo)

Puede generar cada proyecto por separado, pero no puede reconstruir una solución que termina con: No se pudo encontrar el archivo de metadatos 'C.dll'.

Cambiar la referencia de un archivo a un proyecto en la solución ayuda.

2
Liero

En mi caso recibí este mensaje de error por la sencilla razón de que, después de obtener la última versión del proyecto de TFS, el proyecto incorrecto en la solución se marcó como el proyecto de inicio. Elegir el proyecto correcto como el proyecto de inicio resolvió esto por mí.

1
Joe Dyndale

Vaya, parece que este error puede venir de todas partes.

De todos modos, agregué un nuevo controlador WebAPI a mi aplicación MVC y recibí automáticamente todas las referencias de NuGet. Poco más tarde eliminé las referencias de la interfaz de usuario de NuGet, pero olvidé eliminar los archivos usándolos (es decir, System.Http).

Por alguna razón, el error que estaba recibiendo era este, junto con una simple advertencia sobre una variable que no se estaba utilizando.

Comenté que la variable para eliminar al menos la advertencia y la reconstrucción me indicaron todos los archivos que utilizaban la referencia no existente. Después de eliminar esos archivos, todo salió bien.

1
Alexander D

Me enfrenté a este problema. En mi caso, se hizo referencia a varios proyectos de C # como DLL archivos. Cualquier error de tiempo de compilación en un proyecto que se use como archivo DLL (en otros proyectos) daría como resultado una inundación de errores. El motivo es que el error de tiempo de compilación impide la creación del archivo DLL correspondiente, y esto produce una serie de errores en los proyectos que se refieren al archivo DLL faltante.

Por lo tanto, cuando reconstruya en el Explorador de soluciones (ignorando los errores de tiempo de compilación triviales), se producirán errores (un "grupo de metadatos .dll no se pudo encontrar") (lo que hace que piense qué fue lo que hizo mal, aparte de una simple reconstrucción).

Si se enfrenta a este problema, entonces la mejor solución es limpiar la solución y luego construir cada proyecto uno por uno para averiguar qué proyecto está iniciando el error.

1
josepainumkal

Este problema podría ocurrir debido a un error de sintaxis en su código que podría no ser visible debido al error de Meta Data. Así que revise su archivo fuente antes de realizar cualquiera de las acciones en las respuestas anteriores.

1
Hassan Malik

Descubrí que si elimina Microsoft.CSharp Assembly como referencia en el proyecto, obtendrá este error.

1
Mirek

Me encontré con este error con Visual Studio 2015 cuando eliminé la anotación de tipo de una llamada a un método de extensión, que solo dejaba atrás los corchetes angulares.

Así que en lugar de obj.extensionMethod<Type>() tuve obj.extensionMethod<>().

Clasificaría esto como un error en Visual Studio, ya que no veo cómo ese error podría producir ese error.

1
mschwaig

Para mí, el problema era que tenía dos ventanas de Visual Studio abiertas, mi proyecto se estaba ejecutando en depuración en una ventana e intenté construirlo en otra.

Tuve que dejar de depurar y luego me dejó construir con éxito.

1

Estoy de acuerdo todos los aboves sólo una diferencia. En mi caso: estoy usando Visual Studio 2019. Cerré el VS-2019 y abrí con el VS-2017. y reconstruir el proyecto todo funciona muy bien! Para quien en la fecha de mi posición es: 4/19/2019

1
dewelloper
  1. Haga clic derecho en la solución y haga clic en Limpiar.
  2. Haga clic derecho en la solución y haga clic en Reconstruir.
1

En mi caso, resolví este problema después de darme cuenta de que había hecho referencia a un proyecto .Net Framework 4.7 como una dependencia de un proyecto .Net Framework 4.6.1. Después de migrar el proyecto 4.7 a 4.6.1 mi aplicación compiló normalmente

0
Alexandre Lima

Verifique el archivo .csproj del proyecto principal. Visual Studio no lo limpia en caso de que elimine proyectos o modifique referencias en la solución.

Hice referencia a los proyectos antiguos tres veces en el archivo .csproj y la compilación mostró este error en los proyectos eliminados.

0
Tarmo Elfving

Vi este error porque tenía la siguiente línea en mi código (parece que aún estaba pensando en modo SQL):

if(myVar is null)
    DoSomething();

Visual studio (2017) no reportó errores en el momento de diseño o compilación, sin embargo, el proyecto no se generó y dio el error ".dll faltante". Al cambiar la línea errónea a:

if(myVar == null)

El problema fue resuelto.

0
Gavimoss

En mi caso, también tuve un montón de otros errores de compilación (algunas conversiones de tipo simple) junto con este, me estaba rascando la cabeza tratando de resolver esto, y no me estaba enfocando en los otros errores.

Lo que finalmente resolvió mi problema fue que arreglé todos los demás errores de compilación y luego construí nuevamente y construí con éxito.

Entonces, en caso de que tenga otros errores de compilación junto con el error faltante del archivo DLL, y nada más le funcione, intente arreglar los otros errores primero y luego vuelva a compilar la solución.

0

Ninguna de las docenas de respuestas hasta ahora funcionó para mí. En mi caso, también me salió el error:

Nombre de elemento de tupla 'Valor' se infiere. Utilice la versión de idioma 7.1 o superior para acceder a un elemento por su nombre inferido

Apareció junto al "Archivo de metadatos '.dll'. No se encontraron errores" en la construcción, pero desapareció poco después, ya que los errores a veces lo hacen como IDE "se pone al día".

Haciendo doble clic en el error para encontrarlo, y eliminando el código ofensivo, lo arregla.

De lo contrario, puedes probar esto en Visual Studio:

Menú Proyecto → <Nombre del proyecto> Propiedades Generar → botón Avanzado Versión de idioma C # <última versión menor> (por ejemplo, " C # 5.0 ")

Y eso lo arregla también.

Parece que "el archivo de metadatos '.dll' no se pudo encontrar" es a menudo un síntoma de otros problemas subyacentes, por lo que si ninguna de las soluciones principales funciona para usted, verifique otros errores y advertencias e intente encontrar el problema real.

0
MGOwen

Tuve el mismo problema y otra solución.

El problema: una solución, múltiples proyectos. La aplicación principal que usa algunos de los otros resultados falló, diciendo:

CSC: error CS0006: No se pudo encontrar el archivo de metadatos 'C:\Repos\TheApplication\TheApplicationCommon\bin\Debug\TheApplication.dll'

Pero en realidad este Proyecto generó C:\Repos\TheApplication\TheApplicationCommon\bin\Debug\TheApplicationCommon.dll Otro proyecto que también usa la misma dll compilada sin problemas.

Antes de actualizar un paquete interno de NuGet que usaba PostSharp 3.x.x.x y ahora usa PostSharp 4.x.x.x. Y mi solución fue agregar esto a mi archivo * .csproj:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="...">
  <Import Project="..." Condition="..." />
  <PropertyGroup>
    ...
    <AssemblyName>TheApplication</AssemblyName>
    ...
    <SkipPostSharp>True</SkipPostSharp> <!-- This line -->
  </PropertyGroup>
...

Otra Solución-> Limpiar, otra Solución-> Reconstruir y funciona localmente y en el servidor de compilación.

Espero que ayude a alguien. El hilo es antiguo y bastante largo, pero este problema vuelve a menudo y aún no he visto esta solución. Por cierto usando Visual Studio 2017 (15.8.x).

0
ecth

En mi caso dentro de mi archivo Web.config cambiando esto

<?xml version="1.0" encoding="utf-8"?>

a esto

<?xml version="1.0"?>

arreglado mi problema

0
Elnoor

En mi caso, me pasó cuando hacía referencia a los paquetes de NuGet localmente y movía su directorio a otro lugar, cambié la ruta dentro de NuGet.Config pero desafortunadamente descubrí que debía cambiar los archivos .csproject manualmente para actualizar la ruta de referencia, pero el mensaje de error CS0006 estaba muy lejos de describir este problema. Generalmente, también ocurre cuando hay una referencia a DLL que no se pudo encontrar, para poder identificar el problema, busque sus referencias en el proyecto con el problema, encontrará algunas referencias con el icono de advertencia asociado a ellas. , intente arreglarlos y debería funcionar como se espera.

0
Ali Ezzat Odeh

Me enfrenté a este problema después de getting latest (comando Team Foundation Server (TFS)).

Después de resolver los conflictos, encontré usando una declaración para un namespace that does not exist in the project.

Así que eliminé esa declaración using luego clean and rebuild, y todo estaba bien.

0

Cuando hice una compilación, normalmente mostraba errores como este en Visual Studio 2017:

Error   CS0006  Metadata file 'C:\src\ProjectDir\MyApp\bin\x64\Debug\Inspection.exe' could not be found MyApp   C:\src\ProjectDir\MyApp\CSC 1   Active

Pero a veces un error como este se muestra durante un par de segundos y luego desaparece y vuelve al mensaje anterior:

Error   CS1503  Argument 1: cannot convert from 'MyApp.Model.Entities.Asset' to 'MyApp.Model.Model.Entities.Inspection' MyApp   C:\src\ProjectDir\MyApp\ViewModels\AssetDetailsViewModel.cs 1453    Active

Así que pasé un tiempo resolviendo el primer error, pero el problema real se debió al segundo error. Primero tuve que eliminar todos los directorios/bin y/obj, luego también borré los archivos .suo como se indicó anteriormente. Esto me permitió limitar el problema a un problema de interfaz.

En mi interfaz tuve esto:

    Task<IList<Defect>> LoadDefects(Asset asset);

Pero en mi implementación real tuve este código:

    public virtual async Task<IList<Defect>> LoadDefects(Inspection inspection)
    {
       var results ...
       // ....

        return results;
    }

La compilación se completó con éxito después de actualizar la interfaz para esto:

    Task<IList<Defect>> LoadDefects(Inspection inspection);

Así que parece que el almacenamiento en caché en VS hizo que siguiera mostrando el error CS0006 cuando el problema real era el error CS1503.

0
user8128167

Ninguna de las soluciones anteriores funcionó para mí, así que compartiré lo que hizo.

Tuve este problema después de fusionar algunas bibliotecas de clases nuevas de otra rama que se referían entre sí. Eliminar las referencias en los proyectos y recrearlos finalmente solucionó el problema. Al parecer, Visual Studio se había fusionado en las rutas de archivo incorrectas.

0
Nick Van Brunt

Para mí, el problema fue un error que no apareció en el resultado de la compilación, es decir, tuve dos clases de utilidad que estaban en espacios de nombres diferentes inicialmente. Cambié el espacio de nombres de la segunda para que coincida con la primera (sin saber que había otra clase de utilidad en la primera), y ahí fue cuando comenzó a aparecer este error.

Me imagino que surgió el error de salida de compilación porque no se pudo compilar el archivo DLL de la biblioteca de la capa lógica, y la aplicación principal no pudo encontrarlo.

La solución fue volver a cambiar la segunda clase de utilidad a un espacio de nombres diferente y ahí fue cuando empezaron a aparecer los verdaderos errores de compilación. Después de ordenarlos, la compilación se realizó sin problemas.

Como resumen, si alguna de las soluciones anteriores no funciona, es posible que haya eliminado los errores en el código que Visual Studio no muestra, así que intente volver a empaquetar sus pasos de codificación y verifique si hay irregularidades.

PS: Esto fue en Visual Studio 2015 Community Edition

0
Remus.A

Comencé a tener este problema después de cambiar mucho la solución, archivar los cambios y deshacerlos.

La única forma de resolverlo fue eliminando y agregando nuevamente la asignación de TFS a mi carpeta local.

0
NoHero

¡Muy extraño! Probé todas las respuestas anteriores y desafortunadamente nada funcionó en mi caso.

Me encontré con dos errores:

  1. Falta el archivo .dll
  2. Método ya definido en otro lugar con los mismos parámetros.

He borrado el segundo error primero eliminando la función que se ha duplicado en otro lugar.

Mi primer error - es que falta el archivo .dll lo resolví por su cuenta.

Quiero decir, si tiene más de un solo error junto con el error de archivo .dll que falta, por favor, intente resolver los otros errores primero. Tal vez el error .dll lo resuelve por sí solo!

0
A user

En mi caso, establecer el marco de destino resolvió el problema:

  1. Haga clic derecho en el proyecto y seleccione Propiedades

  2. En Aplicación , cambiar Marco de destino al mismo que el proyecto principal (por ejemplo, ".NET Framework 4.5").

0
Hamid

El Visual Studio IDE no hace ningún edificio tras bambalinas, la aplicación Msbuild lo hace. El VS IDE esencialmente simplemente construye el archivo de proyecto que utiliza Msbuild y, a menudo, comete errores si lo deja en IDE para resolver las cosas por sí mismo. Si obtiene el error Metadata file '.dll' could not be found es probable que no se encuentren los ensamblajes correctos/esperados. Entonces, tal vez Visual Studio podría estar creando un archivo de proyecto para una aplicación de marco 4.5 y esperando 4.5 ensamblajes mientras hace referencia a ensamblados 4.0. Así que mire la configuración de Visual Studio para detectar incompatibilidades o ingrese al archivo del proyecto, y corríjalo manualmente especificando la ruta correcta <Reference Include="C:\\correct path to Assembly\\yourAssembly.dll" />.

0
annoying_squid