Não foi possível carregar o arquivo ou montagem 'Microsoft.Build.Framework' (VS 2017)

Quando tento executar o comando "update-database", recebo esta exceção:

Especifique o sinalizador '-Verbose' para visualizar as instruções SQL sendo aplicadas ao banco de dados de destino. System.IO.FileNotFoundException: Não foi possível carregar o arquivo ou assembly 'Microsoft.Build.Framework, Version = 15.1.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' ou uma de suas dependências. O sistema não pode encontrar o arquivo especificado. Nome do arquivo: 'Microsoft.Build.Framework, Version = 15.1.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a'

WRN: O registro de associação de montagem está DESLIGADO. Para habilitar o log de falha de vinculação de assembly, defina o valor do registro [HKLM \ Software \ Microsoft \ Fusion! EnableLog] (DWORD) como 1. Observação: há alguma penalidade de desempenho associada ao log de falha de vinculação de assembly. Para desativar esse recurso, remova o valor do registro [HKLM \ Software \ Microsoft \ Fusion! EnableLog].

Não foi possível carregar o arquivo ou assembly 'Microsoft.Build.Framework, Version = 15.1.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' ou uma de suas dependências. O sistema não pode encontrar o arquivo especificado.

Acredito que tive o mesmo problema que você. Não salvei toda a mensagem de erro, mas minha mensagem de erro foi

' Não foi possível carregar o arquivo ou montagem' Microsoft.Build.Framework, Version = 15.1.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a 'ou uma de suas dependências. O sistema não pode encontrar o arquivo especificado. '

Estou usando o Visual Studio 2017 e estava tentando fazer Update-Databasedepois Add-Migration.

Para resolver o problema, fechei o Visual Studio, abri-o novamente e executei Update-Databasenovamente.

Isso pode ou não resolver seu problema, mas achei melhor postar para o caso de ajudar.

Nosso script de construção local estava usando uma versão mais antiga de nuget.exe( 4.7.1.5393) para restaurar pacotes NuGet. Começamos a receber esse erro depois de atualizar para a versão do Visual Studio 2019 16.5.0. Atualizar para a versão mais recente de nuget.exe( 5.4.0.6315) corrigiu o problema para nós.

nuget.exepode ser baixado aqui: https://www.nuget.org/downloads .

A causa raiz desse problema vem de caminhos relativos no devenv.exe.configarquivo para Microsoft.Build.Framework.dll(consulte as tags xml).

Algumas extensões do Visual Studio estão alterando o diretório atual e tornam os caminhos relativos inválidos.

Para consertar, abra este arquivo no C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\diretório. e substitua tudo ..\..\MSBuild\15.0\Bin\por C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\.

Eu encontrei uma solução alternativa que parece resolver o problema para sempre, pelo menos no meu ambiente executando o VS 2017 Professional 15.5.2 e o Entity Framework 6.1.1.

Basicamente, instale a DLL (com algumas outras relacionadas) no GAC (Global Assembly Cache) e o problema irá embora.

Siga esses passos:

1. Feche todas as instâncias em execução do Visual Studio 2017

2. Inicie o Prompt de Comando do Desenvolvedor do Visual Studio 2017

3. Digite os seguintes comandos (substitua Professional por sua edição, Enterprise ou Community, ou ajuste o caminho de acordo):

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll"

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.dll"

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Engine.dll"

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Conversion.Core.dll"

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Tasks.Core.dll"

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Utilities.Core.dll"

4. Reinicie o Visual Studio 2017

Em essência, o GAC terá (na maioria dos casos) prioridade quando o .NET estiver tentando carregar uma DLL e a FileNotFoundException desaparecerá, pois sua DLL será resolvida por meio do GAC.

Novamente, funciona para mim e é simplesmente uma solução alternativa, não resolverá o problema principal em si, mas pelo menos não tenho que reiniciar o VS o tempo todo ao tentar trabalhar com migrações EF, e isso é bom o suficiente para mim.

Isso funcionou para mim - parece ser um problema sem suporte a partir de 2020.

No Azure Build Pipeline> NuGet tool installerpasso, mude Version of NuGet.exe to installpara uma versão mais recente, como 5.4.0. Verifique as versões em https://dist.nuget.org/tools.json .

O problema desapareceu e agora é compilado com sucesso.

Meu arquivo ausente ou versão de montagem é diferente com a pergunta.

Recebi este erro quando tentei publicar meu projeto ASP.net

Microsoft.Build.Framework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

Resolvi o problema instalando o Microsoft Build Tools 2015

Acho que meu problema foi causado por publicar um projeto que foi construído com o VS 2015 no VS 2017. Espero poder ajudar outras pessoas que tenham o mesmo problema.

Apenas no caso de reiniciar o Visual Studio não funcionar Vá para o Gerenciador de Tarefas / Explorador de Processos e habilidade VBCSCompiler.exe

Sugerir o uso do Process Explorer

Fechar e reabrir o Visual Studio funciona perfeitamente!

No meu caso, algo (talvez um NuGet-Update) adicionou um AssemblyBinding ao arquivo web.config:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-15.1.0.0" newVersion="15.1.0.0" />
</dependentAssembly>

Depois de remover essa entrada de associação dependente, pude publicar o projeto novamente.

Isso funcionou para mim: o erro ocorre quando eu executo o comando nuget restore. Nuget versão 4.6.2. Tenho duas maneiras de resolver esse problema.

Use o Nuget 4.8.2 e superior. gacutil / i "C: \ Arquivos de programas (x86) \ Microsoft Visual Studio \ 2019 \ Professional \ MSBuild \ Current \ Bin \ Microsoft.Build.Framework.dll

Tivemos esse problema e aqui está o que precisávamos fazer em nosso caso:

O problema era que tínhamos um interceptor de comando do banco de dados (IDbCommandInterceptor)configurado que chamava HttpRuntime.Cache["somekey"] e, por algum motivo, os comandos de migração não foram executados por causa disso. Após remover esta dependência, todos os comandos funcionaram perfeitamente. Talvez HttpRuntimenão tenha conseguido encontrar a dll do Build Framework?

Portanto, verifique toda a pilha de chamadas quando os comandos de migração falharem para ver se você tem um problema semelhante.

Eu enfrentei o mesmo problema quando atualizei os componentes do XCode / Mono no macOS.

A solução é atualizar o Visual Studio para Mac para a versão mais recente.

Acho que esse problema causa no uso de novas ferramentas MSBuild do pacote .NET Core 3.0 que é instalado com a nova versão XCode / Mono.

Obrigado a quem já postou. Minha situação foi resolvida por uma combinação das opções acima. Tive várias versões do Visual Studio: 2015, 2017, 2019. Em algum momento, a versão do MSBUILD foi de 15.1 para 15.9 e resolvi esse problema atualizando o C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\devenv.exe.configarquivo para apontar para a biblioteca 15.9. Aqui está um exemplo de uma das entradas:

<dependentAssembly>
      <assemblyIdentity name="Microsoft.Build.Utilities.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
      <bindingRedirect oldVersion="2.0.0.0-99.0.0.0" newVersion="15.9.0.0"/>
      <codeBase version="15.9.0.0" href="..\..\MSBuild\15.0\Bin\Microsoft.Build.Utilities.Core.dll" />
</dependentAssembly>

Usando a edição da Comunidade do Visual Studio 2019. Tentei as outras soluções sem muita sorte, mas depois de limpar o cache do NuGet, o problema pareceu estar resolvido.