O arquivo de metadados ‘.dll’ não foi encontrado

Eu estou trabalhando em um projeto WPF, C # 3.0 e recebo este erro:

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

É assim que faço referência aos meus usercontrols:

 xmlns:vms="clr-namespace:VersionManagementSystem"  

Isso acontece depois de cada construção com falha. A única maneira que posso obter a solução para compilar é comentar todos os meus controles de usuário e reconstruir o projeto, e então eu descomentei o usercontrols e está tudo bem.

Verifiquei as configurações de pedidos e dependencies de construção.

Como você pode ver, parece ter truncado o caminho absoluto do arquivo DLL … Eu li que há um bug com o comprimento. Isso é um problema possível?

É muito chato e ter que comentar, construir e descomentar, a construção está se tornando extremamente cansativa.

Eu acabei de ter o mesmo problema. O Visual Studio não está criando o projeto que está sendo referenciado.

  1. Clique com o botão direito na solução e clique em Propriedades.
  2. Clique em Configuração à esquerda.
  3. Certifique-se de que a checkbox de seleção em “Criar” para o projeto que não pode encontrar esteja marcada. Se já estiver marcado, desmarque, clique em aplicar e marque as checkboxs novamente.

Isso ainda pode acontecer em versões mais recentes do Visual Studio (eu acabei de acontecer no Visual Studio 2013):

Outra coisa para tentar é fechar o Visual Studio e excluir o arquivo .suo que está próximo ao arquivo .sln . (Ele será gerado novamente na próxima vez que você Save all (ou sair do Visual Studio)).

Eu tive esse problema ao adicionar novos projetos para a solução em outra máquina e, em seguida, puxando as revisões, mas o arquivo .suo pode ser corrompido em outros casos também e levar a muito estranho comportamento do Visual Studio, portanto, excluí-lo é um das coisas que eu sempre tento.

Observe que a exclusão do arquivo .suo redefinirá o (s) projeto (s) de boot da solução.

Mais sobre o arquivo .suo está aqui .

A resposta sugerida não funcionou para mim. O erro é um chamariz para outro problema.

Descobri que estava mirando em uma versão ligeiramente diferente do .NET e isso foi sinalizado como um aviso pelo compilador, mas estava causando a falha do edifício. Isso deveria ter sido marcado como um erro e não como um aviso.

Bem, minha resposta não é apenas o resumo de todas as soluções, mas oferece mais do que isso.

Seção 1):

Em soluções gerais:

Eu tive quatro erros desse tipo (‘arquivo de metadados não pôde ser encontrado’) junto com um erro dizendo ‘Arquivo de origem não pôde ser aberto (‘ Erro não especificado ‘)’.

Eu tentei se livrar do erro ‘arquivo de metadados não pôde ser encontrado’. Para isso, li muitos posts, blogs, etc. e achei que essas soluções podem ser eficazes (resumindo-as aqui):

  1. Reinicie o Visual Studio e tente construir novamente.

  2. Vá para ‘Gerenciador de Soluções’ . Clique com o botão direito em Solution. Vá para Propriedades . Vá para ‘Gerenciador de configurações’ . Verifique se as checkboxs de seleção em ‘Build’ estão marcadas ou não. Se algum ou todos eles estiverem desmarcados, verifique-os e tente construir novamente.

  3. Se a (s) solução (ões) acima (s) não funcionarem, siga a sequência mencionada na etapa 2 acima e, mesmo se todas as checkboxs de seleção estiverem marcadas, desmarque-as, verifique novamente e tente construir novamente.

  4. Ordem de construção e dependencies do projeto:

    Vá para ‘Gerenciador de Soluções’ . Clique com o botão direito em Solution. Vá para ‘Dependências do Projeto …’ . Você verá duas guias: ‘Dependências’ e ‘Ordem de construção’ . Esta ordem de construção é aquela em que a solução é construída. Verifique as dependencies do projeto e a ordem de construção para verificar se algum projeto (digamos, ‘projeto1’) que depende de outro (como ‘projeto2’) está tentando construir antes daquele (projeto2). Isso pode ser a causa do erro.

  5. Verifique o caminho do arquivo .dll ausente:

    Verifique o caminho do arquivo .dll ausente. Se o caminho contiver espaço ou qualquer outro caractere de caminho inválido, remova-o e tente construir novamente.

    Se esta for a causa, ajuste a ordem de criação.


Seção 2):

Meu caso particular:

Eu tentei todos os passos acima com várias permutações e combinações com o reinício do Visual Studio algumas vezes. Mas isso não me ajudou.

Então, eu decidi me livrar de outro erro que eu estava encontrando (‘Arquivo de origem não pôde ser aberto (‘ Erro não especificado ‘)’).

Me deparei com uma postagem no blog: Erro do TFS – arquivo de origem não pôde ser aberto (‘Erro não especificado’)

Eu tentei as etapas mencionadas nesse post do blog, e me livrei do erro ‘Arquivo de origem não pôde ser aberto (‘ Erro não especificado ‘)’ e surpreendentemente me livrei de outros erros (‘arquivo de metadados não pôde ser encontrado’) como bem.


Seção (3):

Moral da história:

Experimente todas as soluções mencionadas na seção (1) acima (e quaisquer outras soluções) para se livrar do erro. Se nada funcionar, conforme o blog mencionado na seção (2) acima, exclua as inputs de todos os arquivos de origem que não estejam mais presentes no controle de origem e no sistema de arquivos do arquivo .csproj .

No meu caso, isso foi causado por uma incompatibilidade de versão do .NET Framework.

Um projeto foi 3.5 e o outro projeto de referência 4.6.1.

Fechar e reabrir o Visual Studio 2013 funcionou para mim!

Bem, nada nas respostas anteriores funcionou para mim, então isso me fez pensar sobre o motivo de eu estar clicando e esperando que, como desenvolvedores, devêssemos realmente tentar entender o que está acontecendo aqui.

Pareceu-me óbvio que essa referência de arquivo de metadados incorreta deve ser mantida em algum lugar.

Uma pesquisa rápida do arquivo .csproj mostrou as linhas culpadas. Eu tinha uma seção chamada que parecia estar pendurada no antigo caminho incorreto.

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

Então, uma simples correção realmente:

  1. Faça o backup do seu arquivo .csproj.
  2. Encontre os caminhos incorretos no arquivo .csproj e renomeie apropriadamente.

Por favor, certifique-se de fazer backup do seu antigo .csproj antes de mexer .

Eu tenho o mesmo erro “Arquivo de metadados ‘.dll’ não pôde ser encontrado”, e eu tentei várias coisas descritas acima, mas a razão para o erro foi que eu estava fazendo referência a um arquivo DLL de terceiros que estava visando uma versão .NET superior que meu projeto tem como alvo a versão .NET. Então a solução foi mudar o framework alvo do meu projeto.

Eu também encontrei esse problema. Em primeiro lugar você tem que construir manualmente seu projeto DLL, clicando com o botão direito do mouse, Build. Então vai funcionar.

No meu caso, eu tenho meu diretório instalado de maneira errada.

Se o caminho da sua solução for algo como “Meu Projeto% 2c Muito Popular% 2c Teste de Unidade% 2c Software e Hardware.zip”, ele não pode resolver o arquivo de metadados, talvez devamos evitar algumas palavras inválidas como% 2c.

Renomear o caminho para o nome normal resolveu meu problema.

Eu adicionei um novo projeto à minha solução e comecei a receber isso.

O motivo? O projeto que eu trouxe estava visando um framework .NET diferente (4.6 e meus outros dois eram 4.5.2).

Eu estava puxando o cabelo para fora com este problema também, mas depois de tentar as respostas anteriores a única coisa que funcionou para mim foi abrir cada projeto na minha solução 1 por 1 e construí-los individualmente.

Em seguida, fechei o Visual Studio 2013, reabri a minha solução e compilou tudo bem.

É estranho, porque se eu clicasse em cada projeto no meu Gerenciador de Soluções e tentasse criá-los dessa maneira, todos eles falharam. Eu tive que abri-los sozinho em suas próprias soluções.

Para mim, ocorreu quando incluí um novo projeto em uma solução.

O Visual Studio seleciona automaticamente o .NET Framework 4.5.

Eu mudei para a versão .NET 4.5.2 como as outras bibliotecas, e funcionou.

Para mim, estava tentando encontrar uma DLL em um caminho que costumava conter o Project, mas a movemos para um novo diretório. A solução tinha o caminho correto para o projeto, mas o Visual Studio de alguma forma continuava procurando no local antigo.

Solução: Renomeie cada problema Project – apenas adicione um caractere ou qualquer outra coisa – e renomeie-o de volta ao seu nome original.

Isso deve redefinir algum tipo de cache global de algum tipo no Visual Studio, porque isso elimina esse problema e vários como ele, enquanto coisas como Clean não.

Para mim, os seguintes passos funcionaram:

  • Encontre o projeto que não está construindo
  • Remover / adicionar referências a projetos dentro da solução.

Minha instância do problema foi causada por um projeto comum que tinha um nome de class duplicado (sob um nome de arquivo diferente). É estranho que o Visual Studio não pôde detectar isso e, em vez disso, apenas explodiu o processo de compilation.

Eu tenho esse problema no Visual Studio 2012 em uma solução que tinha muitos projetos. Recriar cada projeto na solução manualmente na mesma ordem que a Ordem de Criação do Projeto (clique com o botão direito do mouse e reconstruir no Solution Explorer) corrigiu para mim.

Finalmente cheguei a um que me deu um erro de compilation. Corrigi o erro e a solução seria construída corretamente depois disso.

No meu caso, o problema foi causado por um simples erro de compilation,

erro CS0067: O evento ‘XYZ’ nunca é usado

que, por qualquer motivo, não apareceu na janela de erro.

Por causa disso, o sistema de compilation do Visual Studio pareceu perder o erro e tentou criar projetos dependentes, o que, por sua vez, falhou com a mensagem de metadados irritante.

A recomendação é tão estúpida quanto possa parecer:

Primeiro, olhe para a sua janela de saída !

Me levou meia hora antes que essa ideia me atingisse …

No meu caso, o problema era que eu excluía manualmente um arquivo de não-compilation que estava marcado como “ausente”. Uma vez eu apaguei a referência para o arquivo que está faltando e recompilei – tudo estava bem.

Eu tive o mesmo problema. No meu caso, o projeto ainda iria construir no modo de liberação e foi apenas quando eu tentei construir na debugging que ele falhou.

O que acabei fazendo para corrigir o problema foi simplesmente copiar todas as dlls (e outros arquivos da minha pasta de lançamento) para a minha pasta de debugging. Depois de fazer isso para cada projeto, os erros desapareceram.

Se você tiver um espaço no nome da sua solução, isso também causará o problema. Remover o espaço do nome da sua solução, de modo que o caminho não contenha% 20 resolverá isso.

Apenas apontando para o óbvio: se você não tem “Mostrar janela de saída quando a compilation começa”, certifique-se de que você está percebendo se sua compilation está falhando (erro pequeno de “falha na compilation” no canto inferior esquerdo) !!!!

Eu tive esse erro quando eu estava tentando publicar um aplicativo da web. Acontece que uma das propriedades de uma class foi envolvida em

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

mas o uso da propriedade não foi. A publicação foi feita na configuração Release sem o símbolo DEBUG , obviamente.

Voltando a isso alguns anos mais tarde, esse problema provavelmente está relacionado ao limite de caminho máximo do Windows:

Nomeando arquivos, caminhos e espaços para nome , Limitação de comprimento máximo de caminho

Estou executando o Visual Studio 2013.

Parece que as dependencies de compilation estavam incorretas. A exclusão dos arquivos * .suo corrigiu os problemas que tive.

Para o meu caso, foi que eu havia comentado as classs em um namespace específico (vazio):

 namespace XYZW { // Class code } 

Quando eu removi o código do namespace e os comandos de importação dele – ele consertou o problema.

Na construção também estava dizendo – junto com o arquivo DLL ausente do projeto:

erro CS0234: O tipo ou nome do namespace ‘W’ não existe no namespace ‘XYZ’ (falta uma referência de assembly?)

Eu também tive o mesmo erro. Esconde-se como no caminho abaixo. O caminho que me referi para o arquivo DLL é como “D: \ Assemblies Folder \ Assembly1.dll”.

Mas o caminho original no qual o assembly se referia era “D: \ Assemblies% 20Folder \ Assembly1.dll”.

Devido a essa variação de nome de caminho, o assembly não pôde ser recuperado de seu caminho original e, portanto, lança o erro “Metadata não encontrado”.

A solução está na questão do Stack Overflow Como substituo todos os espaços por% 20 em c #? .

Este erro pode ser mostrado se você usar montagens falsas. A remoção de falsificações leva ao desenvolvimento bem-sucedido do projeto.

Recebi este erro depois de abrir um projeto no qual o Entity Framework foi referenciado, portanto, excluí essas referências e reinstalei o Entity Framework versão 6.0.0.0 por meio do gerenciador de estoque da seguinte maneira:

 install-package entityframework -version 6.0.0.0 

O erro ainda estava aparecendo, então pensei que essas referências estavam lá porque havia uma versão mais antiga do Entity Framework supostamente “pré-instalada” no projeto, mas não estava realmente funcionando.

Então eu fui até o arquivo packages.config e notei que havia outra referência:

  ****   

Em seguida, apaguei a linha, limpei e reconstruí o projeto e a solução do contêiner, e finalmente funcionou.

Eu tive um problema semelhante quando decompilei uma biblioteca muito antiga, que foi implantada em um ambiente de produção, mas o código-fonte foi perdido.

Tomei .dll, decompilei e gerou projetos e solução. Não consegui criar a solução devido a vários erros desse tipo.

Dicas em respostas anteriores não ajudaram, mas depois de um tempo eu notei referências em falta em alguns projetos para vários assemblies como System.dll.

Suponha que haja um projeto A dependente do projeto B. Não houve referência ao System.dll no projeto B, mas o erro após a compilation era como “Arquivo de metadados ‘B.dll’ não pôde ser encontrado”.

Não houve erro sobre a falta do System.dll no projeto B.

Adicionando referência em bibliotecas como System.dll no projeto B resolveu o problema. (System.Data, System.DirectoryServices, etc.)