Aviso: conflitos encontrados entre versões diferentes do mesmo assembly dependente

Atualmente, estou desenvolvendo um aplicativo .NET, que consiste em 20 projetos. Alguns desses projetos são compilados usando o .NET 3.5, outros ainda são projetos do .NET 2.0 (até agora não há problema).

O problema é que, se eu incluir um componente externo, sempre recebo o seguinte aviso:

"Found conflicts between different versions of the same dependent assembly".

O que exatamente esse aviso significa e existe talvez a possibilidade de excluí-lo (como usar #pragma disable nos arquivos de código-fonte)?

Esse aviso significa que dois projetos fazem referência à mesma montagem (por exemplo System.Windows.Forms), mas os dois projetos exigem versões diferentes. Você tem poucas opções:

1. Recompile todos os projetos para usar as mesmas versões (por exemplo, mova todos para .Net 3.5). Essa é a opção preferida porque todo o código está sendo executado com as versões das dependências com as quais foram compiladas.

2. Adicione um redirecionamento de ligação . Isso suprimirá o aviso. No entanto, seus projetos .Net 2.0 (em tempo de execução) serão vinculados às versões .Net 3.5 de assemblies dependentes, comoSystem.Windows.Forms . Você pode adicionar rapidamente um redirecionamento de ligação clicando duas vezes em erro no Visual Studio.

3. Use CopyLocal=true. Não tenho certeza se isso suprimirá o aviso. Como a opção 2 acima, isso significa que todos os projetos usarão a versão .Net 3.5 do System.Windows.Forms.

Aqui estão algumas maneiras de identificar as referências ofensivas:

• Você pode usar um utilitário como o encontrado em https://gist.github.com/1553265
• Outro método simples é definir a verbosidade de saída da compilação (ferramentas, opções, projetos e soluções, compilar e executar, o detalhamento da saída da compilação do projeto MSBuild, detalhado) e após a compilação, pesquisar o aviso na janela de saída e observar o texto logo acima . (Dica para Pauloya, que sugeriu isso nos comentários desta resposta) .

Basicamente, isso acontece quando os assemblies aos quais você está referenciando têm "Copy Local" definido como "True", o que significa que uma cópia da DLL é colocada na pasta bin junto com o seu exe.

Como o Visual Studio copiará também todas as dependências de um assembly referenciado, é possível terminar com duas compilações diferentes do mesmo assembly que estão sendo referidas. É mais provável que isso aconteça se seus projetos estiverem em soluções separadas e, portanto, podem ser compilados separadamente.

O jeito que eu consegui contornar isso é definir Copy Local como False para referências em projetos de montagem. Faça isso apenas para executáveis ​​/ aplicativos da web em que você precisa da montagem para a execução do produto acabado.

Espero que faça sentido!

Eu queria postar a solução da pauloya que eles forneceram nos comentários acima. Eu acredito que é a melhor solução para encontrar as referências ofensivas.

A maneira mais simples de encontrar o que são as "referências ofensivas" é definir a verbosidade de saída do Build (Ferramentas, Opções, Projetos e Soluções, Build and Run, verbosity de saída do build do projeto MSBuild, Detalhada) e, após a criação, pesquisar na janela de saída para o aviso. Veja o texto logo acima.

Por exemplo, quando você pesquisa "conflito" no painel de saída, pode encontrar algo parecido com isto:

3>  There was a conflict between "EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".
3>      "EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was chosen because it was primary and "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was not.

Como você pode ver, há um conflito entre as versões 5 e 6 do EF.

Eu tive o mesmo problema com um dos meus projetos, no entanto, nenhuma das opções acima ajudou a resolver o aviso. Eu verifiquei o arquivo de log da compilação detalhada, usei o AsmSpy para verificar se usei as versões corretas para cada projeto na solução afetada, verifiquei as entradas reais de cada arquivo do projeto - nada ajudou.

Eventualmente, descobriu-se que o problema era uma dependência aninhada de uma das referências que eu tinha em um projeto. Essa referência (A), por sua vez, exigia uma versão diferente de (B), que era referenciada diretamente de todos os outros projetos em minha solução. A atualização da referência no projeto referenciado resolveu-a.

Solution A
+--Project A
   +--Reference A (version 1.1.0.0)
   +--Reference B
+--Project B
   +--Reference A (version 1.1.0.0)
   +--Reference B
   +--Reference C
+--Project C
   +--Reference X (this indirectly references Reference A, but with e.g. version 1.1.1.0)

Solution B
+--Project A
   +--Reference A (version 1.1.1.0)

Espero que o texto acima mostre o que quero dizer, demorei algumas horas para descobrir, então espero que outra pessoa também se beneficie.

No Visual Studio, se você clicar com o botão direito do mouse na solução e em Gerenciar pacotes de nuget, haverá uma guia "Consolidar" que define todos os pacotes para a mesma versão.

Acabei de receber esta mensagem de aviso, limpei a solução e recompilei (Build -> Clean Solution) e ela foi embora.

Eu tive o mesmo problema e resolvi alterando o seguinte em web.config.

Aconteceu comigo porque estou executando o aplicativo usando o Newtonsoft.Json 4.0

De:

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

Para:

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

Eu tenho outra maneira de fazer isso se você estiver usando o Nuget para gerenciar suas dependências. Descobri que às vezes o VS e o Nuget não correspondem e o Nuget não consegue reconhecer que seus projetos estão fora de sincronia. O packages.config dirá uma coisa, mas o caminho mostrado em References - Properties indicará outra coisa.

Se você deseja atualizar suas dependências, faça o seguinte:

1. No Gerenciador de Soluções, clique com o botão direito do mouse no Projeto e clique em 'Gerenciar Pacotes de Nuget'

2. Selecione a guia 'Pacotes instalados' no painel esquerdo. Grave seus pacotes instalados. Você pode copiar primeiro o packages.config para a área de trabalho, se tiver muito, para poder verificar com o Google para verificar quais pacotes do Nuget estão instalados.

3. Desinstale seus pacotes. Tudo bem, vamos adicioná-los de volta.

4. Instale imediatamente os pacotes que você precisa. O que o Nuget fará não é apenas obter a versão mais recente, mas alterar suas referências e também adicionar os redirecionamentos de ligação para você.

5. Faça isso para todos os seus projetos.

6. No nível da solução, faça uma Limpeza e Reconstrução.

Você pode começar com os projetos mais baixos e seguir para os de nível superior e reconstruir cada projeto à medida que avança.

Se você não deseja atualizar suas dependências, pode usar o console do gerenciador de pacotes e usar a sintaxe Update-Package -ProjectName [yourProjectName] [nome do pacote] [packageName] -Version [versionNumber]

Na verdade, isso depende do seu componente externo. Quando você faz referência a um componente externo em um aplicativo .NET, ele gera um GUID para identificar esse componente. Este erro ocorre quando o componente externo referenciado por um de seus projetos tem o mesmo nome e versão diferente de outro componente em outro assembly.

Às vezes, isso acontece quando você usa "Procurar" para encontrar referências e adicionar a versão errada do assembly, ou você tem uma versão diferente do componente em seu repositório de códigos como a que você instalou na máquina local.

Tente descobrir quais projetos têm esses conflitos, remova os componentes da lista de referência e adicione-os novamente, certificando-se de que você está apontando para o mesmo arquivo.

=> verifique se haverá alguma instância do aplicativo instalada parcialmente.

=> primeiro desinstale essa instância do aplicativo de desinstalação.

=> limpe, reconstrua e tente implantar.

isso resolveu o meu problema. espero que também ajude você. Cumprimentos.

Também teve esse problema - no meu caso, foi causado por ter a propriedade "Versão específica" em várias referências definidas como true. Alterar isso para false nessas referências resolveu o problema.

Se você usasse o NuGet, tudo o que eu precisava fazer era:

1. clique com o botão direito do mouse no projeto e clique em Gerenciar pacotes NuGet.

2. clique na roda dentada no canto superior direito

3. clique na guia Geral no NuGet Package Manager acima das origens do pacote

4. marque "Ignorar Aplicando redirecionamentos de ligação" em Redirecionamentos de ligação

5. Limpe e reconstrua e o aviso se foi

Mole-mole

Passei algum tempo depurando o mesmo problema. Observe que esse problema pode não estar entre projetos diferentes, mas na verdade entre várias referências em um projeto que dependem de versões diferentes da mesma dll / assembly. No meu caso, o problema era referênciaFastMember.dll incompatibilidade de versões de que vem de dois pacotes NuGet diferentes em um único projeto. Quando recebi um projeto, ele não foi compilado porque os pacotes NuGet estavam ausentes e o VS se recusou a restaurar os pacotes ausentes. Através do menu NuGet, atualizo manualmente todos os NuGets para a versão mais recente, ou seja, quando o aviso aparece.

No Visual Studio, Tools > Options > Build and Run > MSBuld Project build output verbosity: (set to) Diagnostics.procure as linhas There was a conflict betweenna Outputjanela. Abaixo está a parte da saída que recebi:

1>  There was a conflict between "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" and "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null". (TaskId:19)
1>      "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" was chosen because it was primary and "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null" was not. (TaskId:19)
1>      References which depend on "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" [C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll]. (TaskId:19)
1>          C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll (TaskId:19)
1>            Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll". (TaskId:19)
1>              FastMember, Version=1.5.0.0, Culture=neutral, processorArchitecture=MSIL (TaskId:19)
1>      References which depend on "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null" []. (TaskId:19)
1>          C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll (TaskId:19)
1>            Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll". (TaskId:19)
1>              ClosedXML, Version=0.94.2.0, Culture=neutral, processorArchitecture=MSIL (TaskId:19)

Notar que Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll"

ClosedXML.dllvem do ClosedXMLNuGet e depende FastMember.dll 1.3.0.0. Além disso, também há FastMemberNuget no projeto, e ele possui FastMember.dll 1.5.0.0. Incompatibilidade!

Eu desinstalei o ClosedXML& FastMemberNuGets, porque eu tinha redirecionamento de ligação e instalei apenas a versão mais recente do ClosedXMLIsso corrigiu o problema!

Isso aconteceu comigo também. Uma dll foi referenciada duas vezes: uma diretamente (em referências) e outra indiretamente (referenciada por outro projeto referenciado). Eu removi a referência direta, a solução limpa e reconstruída. Problema resolvido.

1. Abra o "Gerenciador de Soluções".
2. Clique em "Mostrar todos os arquivos"
3. Expandir "Referências"
4. Você verá uma (ou mais) referência (s) com ícone ligeiramente diferente do resto. Normalmente, é com uma caixa amarela, sugerindo que você tome nota disso. Apenas remova-o.
5. Adicione a referência novamente e compile seu código.
6. Isso é tudo.

No meu caso, houve um problema com a referência do MySQL. De alguma forma, eu poderia listar três versões dele sob a lista de todas as referências disponíveis; para .net 2.0, .net 4.0 e .net 4.5. Eu segui o processo 1 a 6 acima e funcionou para mim.

Outra coisa a considerar e verificar é se você não tem nenhum serviço em execução que esteja usando essa pasta bin. se for parar o serviço e reconstruir a solução

Parece haver um problema no Mac Visual Studio ao editar arquivos .resx. Realmente não sei o que aconteceu, mas tive esse problema assim que editei alguns arquivos .resx no meu Mac. Abri o projeto no Windows, abri os arquivos e eles eram como se não tivessem sido editados. Então eu os editei, salvei e tudo começou a funcionar novamente no Mac também.

Eu tive esse problema quando meu projeto fez referência ao NETStandardLibrary e um dos assemblies referenciados foi publicado para o netcore. Apenas publicou como padrão de rede e o problema desapareceu

Aqui está a solução, estilo .NET Core 3.0: https://github.com/HTD/ref-check

Quando você descobrir quais conflitos, talvez você possa resolvê-los. Se as referências conflitantes forem de outros pacotes, você não terá sorte ou precisará usar fontes.

No meu caso, os pacotes conflitantes costumam ser meus, para que eu possa corrigir problemas de dependência e republicá-los.