Foram encontrados conflitos entre versões diferentes do mesmo assembly dependente que não puderam ser resolvidos


371

Quando eu limpo e construo minha solução que possui vários projetos, a janela de saída informa que a compilação foi bem-sucedida. No entanto, quando visualizo a janela da lista de erros , ele me mostra este aviso:

Foram encontrados conflitos entre versões diferentes do mesmo assembly dependente que não puderam ser resolvidos. Esses conflitos de referência são listados no log de construção quando a verbosidade do log é definida como detalhada. C: \ Arquivos de programas (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets

Quando clico duas vezes nessa mensagem, ele abre o arquivo C: \ Arquivos de Programas (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets, mas não entendo nada nele.

Estou usando o Visual Studio Express 2013 para a Web.

Como descubro o que há de errado e com qual DLL e como faço para que o aviso apague?



2
I submetidos a sugestão MS Ligue para incluir o nome DLL na mensagem connect.microsoft.com/VisualStudio/feedback/details/2619450
Michael Freidgeim

Respostas:


513

eta: Há um artigo matador sobre esse material do próprio Nick Craver da SO que você deve ler


Enquanto as outras respostas dizem isso, elas não explicitam, então eu irei ...

No VS2013.2, para realmente acionar a emissão das informações citadas, você não precisa ler a mensagem, que diz:

C: \ Arquivos de programas (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): aviso MSB3277: Foram encontrados conflitos entre versões diferentes do mesmo assembly dependente que não puderam ser resolvidas. Esses conflitos de referência são listados no log de construção quando a verbosidade do log é definida como detalhada .

Isso está incorreto (ou pelo menos foi para algumas versões do Visual Studio - parece estar bom em uma atualização 3 do VS2015 atualizada ou posterior). Em vez disso, coloque-o em Diagnóstico (em Ferramentas-> Opções-> Projeto e soluções-> Compilar e executar , defina a verbosidade de saída da compilação do projeto MSBuild ); em seguida, você verá mensagens como:

Houve um conflito entre "Newtonsoft.Json, Versão = 6.0.0.0, Cultura = neutra, PublicKeyToken = 30ad4fe6b2a6aeed" e "Newtonsoft.Json, Versão = 6.0.5.17707, Cultura = neutra, PublicKeyToken = 30ad4fe6b2a6aeed".

  • "Newtonsoft.Json, Versão = 6.0.0.0, Cultura = neutro, PublicKeyToken = 30ad4fe6b2a6aeed" foi escolhido porque era primário e "Newtonsoft.Json, Versão = 6.0.5.17707, Cultura = neutro, PublicKeyToken = 30ad4fe6b2a6aeed" não.

Então

  • Ctrl-Alt-O para ir para a janela de saída Build
  • procure " foi escolhido " para encontrar a pesquisa detalhada.

... E sim, para aqueles que olham os detalhes da mensagem [diagnóstico], foi notícia para esse ignorante que existe uma convenção na cidade em que todas as 6.xversões são, internamente, a versão da montagem 6.0.0.0, ou seja, apenas o componente SemVer Major entra na montagem Version :)


3
Obrigado - use o Visual Studio há muitos anos e nunca teve um problema que exigisse cavar isso profundamente no log de compilação. Problema diferente, mas percebendo que as informações que eu estava procurando estavam sendo emitidas em algum lugar, resolviam meu problema.
Timothy Lee Russell

4
O nível de log detalhado parece funcionar dentro do VS (portanto, não é necessário diagnóstico). Não seria a primeira vez que o MSBuild se comporta de maneira diferente no VS ....
Johannes Rudolph

105
Para alterar a verbosidade do log no menu Ferramentas-> Opções, localize Projeto e soluções-> Construir e executar
Jenn

3
No meu caso, eu tive três conflitos e um deles foi responsável pelos outros dois. Copiei meu log de compilação "detalhado" no Bloco de Notas, procurei por "conflito", atualizei o pacote NuGet para a referência que reconheci e o problema foi resolvido.
Isaac Lyman

@robotnik Obrigado pela sugestão de edição [que foi negada por outras pessoas]. Na verdade, eu incluí as informações na parte inferior da resposta, mas espero que a resposta como ela seja agora seja tão clara quanto você pretendia.
Ruben Bartelink

76

Execute msbuild Foo.sln /t:Rebuild /v:diag(from C:\Program Files (x86)\MSBuild\12.0\bin) para criar sua solução a partir da linha de comando e obtenha um pouco mais de detalhes, encontre o .csproj.que registra o aviso e verifique suas referências e referências de outros projetos que usam o mesmo assembly comum que difere na versão.

Editar: Você também pode definir a verbosidade da compilação diretamente no VS2013. Vamos paraTools > Optionsmenu, vá para Projects and Solutionse defina a verbosidade do MSBuild como Diagnostic.

Edit: Poucos esclarecimentos, pois acabei de receber um. No meu caso, o aviso foi devido a adição de uma referência usando o prompt do Resharper, em oposição à caixa de diálogo Adicionar referência, que o fez sem versão, mesmo que a v4 e a v12 estejam disponíveis para você escolher.

<Reference Include="Microsoft.Build, Version=12.0.0.0, ..." />
<Reference Include="Microsoft.Build.Framework" />

vs

<Reference Include="Microsoft.Build, Version=12.0.0.0, ..." />
<Reference Include="Microsoft.Build.Framework, Version=12.0.0.0, ..." />

No log do MSBuild com /v:diagverbosidade, parecia o seguinte. detalhando quais duas referências conflitavam:

  There was a conflict between 
  "Microsoft.Build.Framework, Version=4.0.0.0, ..." and 
  "Microsoft.Build.Framework, Version=12.0.0.0, ...". (TaskId:16)

      "Microsoft.Build.Framework, Version=4.0.0.0, ..." was chosen because it was primary and 
      "Microsoft.Build.Framework, Version=12.0.0.0, ..." was not. (TaskId:16)

      References which depend on "Microsoft.Build.Framework, Version=4.0.0.0, ..." 
      [C:\...\v4.5.1\Microsoft.Build.Framework.dll]. (TaskId:16)

          C:\...\v4.5.1\Microsoft.Build.Framework.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v4.5.1\Microsoft.Build.Framework.dll". (TaskId:16)
              Microsoft.Build.Framework (TaskId:16)

      References which depend on "Microsoft.Build.Framework, Version=12.0.0.0, ..." 
      [C:\...\v12.0\Microsoft.Build.Framework.dll]. (TaskId:16)

          C:\...\v12.0\Microsoft.Build.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v12.0\Microsoft.Build.dll". (TaskId:16)
              Microsoft.Build, Version=12.0.0.0, ... (TaskId:16)

          C:\...\v12.0\Microsoft.Build.Engine.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v12.0\Microsoft.Build.Engine.dll". (TaskId:16)
              Microsoft.Build, Version=12.0.0.0, ... (TaskId:16)

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3277: 
Found conflicts between different versions of the same dependent assembly that could not be resolved.  
These reference conflicts are listed in the build log when log verbosity is set to detailed. 
[C:\Users\Ilya.Kozhevnikov\Dropbox\BuildTree\BuildTree\BuildTree.csproj]

10
Acabei canalizando esse comando para um arquivo de log, para que eu pudesse examiná-lo com mais facilidade:msbuild "Foo.sln" /t:Rebuild /v:d > build.log
CrazyPyro

2
Melhor maneira de chegar ao terminal para isso: stackoverflow.com/a/22702405/268066
CrazyPyro

@CrazyPyro msbuild tem um "construído em" pipe - /l:FileLogger,Microsoft.Build.Engine;logfile=build.log- observe os interruptores para madeireiros explicação aqui
drzaus

3
Onde está localizado o "log de construção"? Como o encontro?
Prisioneiro ZERO

Esta resposta mostra como obter mais detalhes do msbuild, que é o que preocupa um usuário mono. Todas as outras respostas assumem que você está usando o VS e executando em um ambiente Windows.
esperando

39

Só posso apoiar mais a resposta de Ruben com uma comparação entre as duas mensagens exibidas:

insira a descrição da imagem aqui

e a mensagem:

C: \ Arquivos de programas (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): aviso MSB3277: Foram encontrados conflitos entre versões diferentes do mesmo assembly dependente que não puderam ser resolvidas. Esses conflitos de referência são listados no log de construção quando a verbosidade do log é definida como detalhada .

Então, Ruben está certo - isso simplesmente não é verdade. Não há conflitos, apenas uma assembléia ausente. Isso é especialmente chato quando o projeto é um aplicativo ASP.NET, pois as visualizações são compiladas sob demanda , ou seja, imediatamente antes da exibição pela primeira vez. É quando é necessário ter a montagem disponível. (Existe uma opção para pré-compilar as visualizações juntamente com o restante do código, mas isso é outra história .) Por outro lado, se você definir a verbosidade como Diagnóstico, obterá a seguinte saída:

C: \ Arquivos de programas (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): aviso MSB3245: Não foi possível resolver esta referência. Não foi possível localizar o assembly "System.Web.Razor, versão = 3.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL". Verifique se a montagem existe no disco. Se essa referência for exigida pelo seu código, você poderá obter erros de compilação.

Como resultado, tudo o que você precisa fazer é:

  1. Adicione uma referência ao assembly manualmente (localize-o no disco, talvez GAC, e adicione-o como uma referência "direta") ou
  2. Use o pacote NuGet (se publicado na galeria) para fazer o download e fazer referência à montagem contida nele.

Mais sobre a galeria NuGet aqui . Mais sobre a pré-compilação de visualizações do ASP.NET aqui .


No VS 2017, quando defino o "Detalhamento da saída da compilação do projeto MSBuild" (não o arquivo de log) como Detalhado (não Diagnóstico), recebi o erro "Não foi possível localizar o assembly" na minha janela Saída.
ALEXintlsos

@ALEXintlsos: aparentemente essa funcionalidade foi alterada; ainda assim, você tem o erro onde quer que esteja - siga as instruções para se livrar dele.
Alexander Christov 28/11

22

Alterar a verbosidade de construção no visual studio ajudará a apontar na direção certa. Siga as etapas abaixo para alterar a verbosidade no VS

  1. Vá para Ferramentas-> menu Opções no VS
  2. Abrir Projetos e Soluções-> Construir e Executar
  3. Altere o valor da verbosidade de saída da compilação do projeto MSBuild. Escolha um dos Quiet, Minimal, Normal, DetailedeDiagnostic

Verifique a janela de saída ( Ctrl+ Alt+ O) no VS para ver as alterações no log de compilação.


16

e como faço para que o aviso desapareça?

Você provavelmente terá que reinstalar ou atualizar seus pacotes NuGet para corrigir isso.


2
Isso, com uma combinação de reiniciar o Visual Studio quando ele se recusou a reinstalar um pacote corretamente, resolveu o problema para mim.
Ohad Schneider

22
Maneira mais simples de verificar: Clique com o botão direito do mouse na solução -> Manage NuGet packages for solution-> Abaixo, Consolidatevocê pode ver se há versões diferentes do mesmo pacote instaladas
elshev

16

Reiterando um dos comentários de @elshev Clique com o botão direito do mouse na solução -> Gerenciar pacotes NuGet para solução -> Em Consolidar, você pode ver se há versões diferentes do mesmo pacote instaladas. Atualize os pacotes lá. O erro de conflito foi resolvido.


11
isso não resolveu para mim. Eu tive que desinstalar o Newtonsoft.JSON e reinstalar através do NuGet. Isso atualizou dependências nos outros pacotes.
precisa

Isso também aconteceu comigo ao usar ferramentas como o Resharper, que adiciona automaticamente referências ausentes da DLL. "Sempre adicionar usando nuget" pode ser uma boa sugestão aqui.
Shaswat Rungta

Isso não funciona para mim porque, ao desinstalar um pacote, ele tenta uma compilação que não pode acontecer porque há um conflito de pacotes. Por isso, sou incapaz de reinstalar o pacote :(
nickornotto

8

Estou usando o Visual Studio 2017 e o encontrei quando atualizei alguns pacotes Nuget. O que funcionou para mim foi abrir meu web.configarquivo, encontrar o <runtime><assemblyBinding>nó e excluí-lo. Salve web.confige reconstrua o projeto.

Olhe para a Error Listjanela. Você verá o que parece ser um aviso massivamente longo sobre conflitos de ligação. Clique duas vezes nele e ele recriará automaticamente o <runtime><assemblyBinding>bloco com os mapeamentos corretos.



3

Eu poderia resolver isso instalando o Newtonsoft Json no projeto da web com pacotes de nugget


3

Obviamente, existem muitas causas diferentes e, portanto, muitas soluções para esse problema. Para colocar o meu na mistura, atualizamos um assembly (System.Net.Http) anteriormente referenciado diretamente em nosso projeto na Web para uma versão gerenciada pelo NuGet. Isso removeu a referência direta dentro desse projeto, mas nosso projeto de teste ainda continha a referência direta. A atualização dos dois projetos para usar o assembly gerenciado pelo NuGet resolveu o problema.


2

Se você fez alterações nos pacotes - reabra o sln. Isso funcionou para mim!


1

Descobri que, às vezes, os pacotes de nuget são instalados (o que eu acho) são os componentes necessários do .NET Core ou outros itens que entram em conflito com a estrutura já instalada. Minha solução foi abrir o arquivo do projeto (.csproj) e remover essas referências. Por exemplo, System.IO, System.Threading e outros tendem a ser adicionados quando o Microsoft.Bcl é incluído por meio de algum pacote NuGet instalado recentemente. Não há razão para versões específicas delas em meus projetos, portanto, removo as referências e a criação do projeto. Espero que ajude.

Você pode procurar no arquivo de projeto por "referência" e remover os conflitos. Se eles estiverem incluídos no System, livre-se deles e a compilação deverá funcionar. Isso pode não responder a todos os casos desse problema - garanto que você sabe o que funcionou para mim :)

Exemplo do que eu comentei:

<!-- <Reference Include="System.Runtime, Version=2.6.9.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"> -->
  <!-- <HintPath>$(SolutionDir)packages\Microsoft.Bcl.1.1.9\lib\net40\System.Runtime.dll</HintPath> -->
  <!-- <Private>True</Private> -->
<!-- </Reference> -->


1

Segui o conselho de várias respostas aqui para descobrir o que estava errado, mas nenhuma das respostas parecia explicar como corrigi-lo. Meu problema foi que uma referência exigia uma versão diferente de uma segunda referência. Portanto, a Newtonsoft estava na versão 6, mas alguma outra DLL queria o 4.5. Atualizei a Newtonsoft como uma das outras respostas sugeridas e que piorou as coisas.

Então, na verdade, eu rebaixei minha instalação do Newtonsoft e o aviso foi embora (VS 2017):

Clique com o botão direito do mouse em Referências no gerenciador de soluções e selecione Gerenciar pacotes NuGet ... Na guia "Instalado", localize Newtonsoft (ou qualquer que seja o seu conflito). No lado direito, uma lista suspensa aparece ao lado de "Versão" que você pode alterar para mais antiga versões. Não era óbvio para mim que esse menu suspenso poderia ser usado para fazer o downgrade.


1

Você pode executar a CLI do Dotnet com total detalhamento do diagnóstico para ajudar a encontrar o problema.

dotnet run --verbosity diagnostic >> full_build.log

Após a conclusão da construção, você pode procurar no erro o arquivo de log (full_build.log). Procurar "um conflito", por exemplo, deve levar você diretamente ao problema.


0

Eu desinstalei o Microsoft ASP.NET MVC nuget.org do Manage NuGet Packagaes e o reinstale novamente. Durante a reinstalação, resolveu todos os conflitos relacionados à versão do razor. Tente .


0

Alterei a verbosidade do MSBuild para Diagnostic.but não conseguia encontrar onde estava o problema, de acordo com as respostas acima, eu tinha esse código no app.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
<sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="XbimXplorer.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
</sectionGroup>
</configSections>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>

Então, acabei de alterar o primeiro sistema, versão de 4.0.0.0 para 12.0.0.0 e meu projeto funcionou.


0

De acordo com as outras respostas, defina o nível de log de saída como detalhado e procure por conflitos, que informarão onde procurar em seguida.

No meu caso, ele me enviou em algumas direções, procurando a fonte das referências, mas no final, descobriu-se que o problema era um dos meus projetos de bibliotecas de classes portáteis, estava mirando a versão errada e estava fazendo o seu próprio versão das referências em, daí os conflitos. Um rápido redirecionamento e o problema foi resolvido.


0

Acabei de me deparar com isso e com o problema depois de mudar um pacote de nuget para dlls localmente referenciadas. O problema era o material antigo de ligação em tempo de execução app.config.


0

Recebi esse aviso depois de migrar para a Referência do pacote. Na saída de diagnóstico, havia informações de que a biblioteca foi referenciada pela mesma biblioteca. Pode ser um bug da nova Referência de Pacote. A solução foi ativar o AutoGenerateBindingRedirects e excluir o redirecionamento de ligação personalizado.


0

VS 2017, projeto MVC

Não sei por que, mas para mim, a solução para esse problema foi remover um outparâmetro de uma assinatura de método de modelo que foi chamada a partir do método de ação do controlador. esse é um comportamento muito estranho , mas essa foi a solução para o meu problema.


-2

Corre Update-Package comando via Console do Gerenciador de Pacotes

Isso corrigirá o MSB3277; o que ele faz é reinstalar todos os pacotes e todos os conjuntos relacionados que eles vêm com a versão mais alta possível . Também é possível atualizar apenas pacotes específicos. Ou faça o downgrade após a atualização, se necessário, esse problema corrigido para mim algumas vezes. Dependendo de quantos pacotes de nuget você possui, esse processo pode levar alguns minutos.

Mais informações sobre os documentos oficiais https://docs.microsoft.com/en-us/nuget/consume-packages/reinstalling-and-updating-packages


14
Esse conselho pode arruinar o seu dia se você não quiser os pacotes mais recentes, que costumam ser o caso do código de produção.
Tony O'Hagan

11
Isso é indicado nos conselhos e o que pode ser um problema para você, é uma maneira fácil e segura de corrigir um problema; portanto, não diminua o voto das pessoas por sua própria opinião.
Aistis Taraskevicius

11
Esta solução não funcionou para mim. Eu já tinha todas as versões mais recentes.
Zero3 25/09

@ Zero3 têm executou-lo da sua solução de topo, sem especificar qualquer pacote diretamente, ele funciona normalmente, porque reinstalar cada um único e referências atualizações, que é o que faz com que são cedidos
Aistis Taraskevicius

3
Este é realmente um péssimo conselho. Não é opinião, atualizar pacotes quebra o código se não for feito com a intenção.
The Batman
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.