Por que estou recebendo 'Assembly' * .dll 'deve ter uma assinatura forte para ser marcado como um pré-requisito.'?

Estou tentando compilar meu suplemento do Excel usando o C # 4.0 e comecei a obter esse problema ao criar meu projeto no Visual Studio. É importante dizer que eu não tive esse problema antes. O que poderia causar isso?

Meu palpite é que você não está trabalhando com assemblies fortemente nomeados. Eu tive esse erro quando dois projetos fazem referência a versões ligeiramente diferentes do mesmo assembly e um projeto mais dependente faz referência a esses projetos. A resolução no meu caso foi remover as informações de chave e versão do nome do assembly nos arquivos .csproj (isso não importava mesmo) e fazer uma compilação limpa.

As alterações entre as diferentes versões de montagem eram compatíveis com as partes da solução referentes a elas. Se esse não for o seu caso, talvez seja necessário mais trabalho para resolver o problema.

NuGet

Com o NuGet, é fácil entrar nessa situação se:

1. Você instala um pacote em um projeto na sua solução.
2. Uma nova versão desse pacote é implantada na origem do pacote.
3. Você o instala em outro projeto na mesma solução.

Isso resulta em dois projetos em sua solução que referenciam versões diferentes dos assemblies desse pacote. Se um deles referenciar o outro e for um aplicativo ClickOnce, você verá esse problema.

Para corrigir isso, emita o update-package [package name]comando no Nuget Package Manager Console para trazer tudo para um campo de jogo nivelado, quando o problema desaparecer.

Você deve gerenciar os pacotes NuGet no nível da solução e não no nível do projeto, a menos que haja um motivo convincente para não fazê-lo. O gerenciamento de pacotes no nível da solução evita o potencial de várias versões de dependências. Ao usar a interface do usuário de gerenciamento, se a guia Consolidado mostrar 1 ou mais pacotes com várias versões, considere consolidá-los em um.

Quando tive esse problema, eu o corrigi desativando as 'Ativar configurações de segurança do ClickOnce'.

Menu: Projeto | Propriedades 'Nome do projeto' ... | Guia Segurança | Caixa de seleção 'Ativar configurações de segurança ClickOnce'.

Veja esta resposta .

Vá para a página de publicação e clique em "Arquivos de aplicativos". A partir daí, você deve ver uma lista das suas DLLs. Verifique se os que estão causando problemas têm o status de publicação marcado como "Incluir" em vez de "Pré-requisito".

Eu tive esse problema. Isso aconteceu porque eu tinha muitos projetos apontando para a mesma montagem, mas de versões diferentes. Eu resolvo selecionando a mesma versão para todos os projetos em minha solução.

Se você alterou a versão do assembly ou copiou uma versão diferente da biblioteca gerenciada indicada no erro, também poderá ter arquivos compilados anteriormente referenciando a versão incorreta. Uma 'Reconstruir tudo' (ou excluir as pastas 'bin' e 'obj' conforme mencionado em um comentário anterior) deve corrigir esse caso.

você precisa assinar a montagem com uma chave. Acesse as propriedades do projeto na guia Assinatura:

Adicionar minha solução para esse problema para qualquer pessoa pode ajudar.

Eu tive uma solução ClickOnce lançando esse erro. O aplicativo referenciou uma pasta "Libs" comum e continha uma referência de projeto a um Foo.dll. Embora nenhum dos projetos na solução tenha feito referência à cópia estática da Foo.dllpasta "Libs", algumas das referências nessa pasta fizeram (por exemplo: minha solução tinha Libs\Bar.dllreferências a que se referia Foo.dll.) Como o aplicativo CO retirou todas as dependências de Libsalém de suas dependências, as duas cópias estavam entrando no projeto. Isso estava gerando o erro acima.

Corrigi o problema movendo minha Libs\Foo.dllversão estática para uma subpasta Libs\Fix\Foo.dll,. Essa alteração fez com que o aplicativo ClickOnce usasse apenas a versão do projeto da DLL e o erro desapareceu.

A exclusão da DLL (onde ocorreu o erro) e a reconstrução da solução corrigiram o meu problema. obrigado

Se você tentou todas as outras respostas nesta pergunta e você:

• Tenha vários projetos em sua solução
• Tenha um projeto (Projeto A) que faça referência a outro projeto (Projeto B), cujo projeto faça referência a um pacote NuGet.
• No Projeto A, você usou o Intellisense / ReSharper para trazer a referência ao pacote NuGet mencionado no Projeto B (isso pode acontecer quando um método no Projeto B retorna um tipo fornecido pelo pacote NuGet e esse método é usado no Projeto A)
• atualizou o pacote NuGet por meio do NuGet Package Manager (ou CLI).

... você pode ter versões separadas da DLL de pacotes do NuGet nas referências de seus projetos, pois a referência criada pelo Intellisense / ReSharper será uma referência "normal" e não uma referência do NuGet conforme o esperado, portanto o processo de atualização do NuGet venceu " Não o encontre ou atualize!

Para corrigir isso, remova a referência no Projeto A, use o NuGet para instalá-lo e verifique se os pacotes do NuGet em todos os projetos são da mesma versão. (como explicado nesta resposta )

Dica Life Pro:

Esse problema pode surgir sempre que o ReSharper / Intellisense sugere adicionar uma referência ao seu projeto. Pode ser muito mais complicado do que o exemplo acima, com vários projetos e dependências entrelaçados dificultando o rastreamento. Se a referência sugerida pelo ReSharper / Intellisense for realmente de um pacote NuGet, use o NuGet para instalá-lo.

Quando isso aconteceu comigo com o WindowsAPICodePack após a atualização, acabei de reconstruir a solução.

Compilar -> Reconstruir Solução

Havia muitos projetos em minha solução para serem executados e atualizados individualmente, então eu o corrigi:

• Clique com o botão direito do mouse em minha solução e selecione 'Gerenciar pacotes NuGet para solução ...'
• Indo para a guia Atualizações
• Localizando o pacote afetado e selecionando Atualizar
• Clicou em OK e isso atualizou todas as instâncias do pacote

Descarregar e recarregar o projeto do problema o resolveu para mim.

Fui publicar , arquivos de aplicativos, encontrei a dll lançando o erro alterou-o para 'Incluir' em 'Incluir (Auto)'. Agora eu posso publicar.

Encontrei esse problema depois de migrar um suplemento do Excel de packages.config para PackageReference. Parece estar relacionado a esse problema .

O seguinte funciona como uma solução alternativa bruta se você não estiver usando o ClickOnce (ele omitirá todas as informações de dependência do .manifestarquivo):

1. Descarregar projeto, editar .csproj

2. Encontre a seção assim:

   <!-- Include additional build rules for an Office application add-in. -->
   <Import Project="$(VSToolsPath)\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets" Condition="'$(VSToolsPath)' != ''" />

3. Edite uma cópia renomeada do .targetsarquivo referenciado (no meu caso, o arquivo foi resolvido C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targetse eu fiz uma cópia Microsoft.VisualStudio.Tools.Office_FIX.targetsna mesma pasta - não verifiquei se funciona em uma pasta diferente).

4. Encontre o GenerateApplicationManifestelemento e altere seu atributo Dependencies="@(DependenciesForGam)"para Dependencies="".

5. Altere a seção encontrada em 2. para referenciar seu .targetsarquivo editado .

Isso precisará ser repetido sempre que a versão do .targetsarquivo enviado com o VS for atualizada (ou você não receberá as atualizações), mas espero que seja corrigido em breve ...

Sua montagem está devidamente assinada?

Para verificar isso, pressione Alt + Enter no seu projeto (ou clique com o botão direito do mouse em Propriedades). Vá para "Assinatura". Verifique se a caixa de seleção "Assinar a montagem" está marcada e se o arquivo de chave de nome forte está selecionado e "Somente sinal de atraso" está desmarcado .

Agora, aqui está uma abordagem diferente para o problema:

• Clique com o botão direito do mouse no projeto e selecione a opção 'Descarregar projeto'. Você notará que seu projeto se torna indisponível.

• Clique com o botão direito do mouse no projeto indisponível e selecione a opção 'Editar'.

• Role para baixo até a tag '<ItemGroup>' que contém todas as tags de recurso.

• Agora vá para a referência que foi exibida na lista de erros, você notará que ele usa uma única tag (ou seja < Reference Include="assemble_name_here, Version=0.0.0.0, Culture=neutral" / >).

• Mude para que fique da seguinte maneira:

.

<Reference Include="assemble_name_here, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL" >
    < Private > True < / Private >
    < HintPath > path_here\assemble_name_here.dll < / HintPath >
< / Reference >

• Salve suas alterações. Clique com o botão direito do mouse no projeto indisponível novamente e clique na opção 'Recarregar projeto' e depois construa.

Isso é causado quando você altera a versão da DLL que é referenciada. Você precisa excluir todos os itens ou a DLL na pasta de criação de destino.

Eu recebi o erro semelhante do compilador. Depois de adicionar o projeto dependente do arquivo DLL à solução, o problema foi resolvido.

Se o seu projeto principal estiver usando alguns projetos de biblioteca e tiver referência a eles, você poderá causar esse problema se o seu projeto fizer referência a um arquivo dll de assembly em vez de ao projeto de biblioteca quando você alterar algo no seu projeto de biblioteca (por exemplo: renomeie uma classe).

Você pode verificar todas as referências ao seu projeto principal, visualizando na janela Pesquisador de objetos (menu Exibir-> Pesquisador de objetos). Uma referência a um arquivo DLL sempre tem um número de versão. Ex: TestLib [1.0.0.0]

Solução: exclua a referência atual do seu projeto principal para o projeto da biblioteca e adicione a referência ao projeto da biblioteca novamente.

Depois de experimentar a maioria das soluções aqui, finalmente adicionei uma referência ao projeto no projeto click once, isso foi alterado para Include (Auto) de Include e finalmente funcionou.

O que me ajudou foi: eu fui para o Package Manager Solution e verifiquei o pacote instalado que estava causando o problema. Vi que vários projetos faziam referência ao mesmo pacote, mas versões diferentes. Alinhei-os com base nas minhas necessidades e funcionou.

Eu tive isso em uma solução com 6 projetos. Um dos meus projetos estava se referindo ao assembly nomeado como uma referência de arquivo. Os outros estavam todos apontando para a referência do projeto.

Normalmente, recebo um erro diferente nesses casos.

Minha solução foi excluir o assembly nomeado em qualquer lugar em que foi referenciado e adicioná-lo novamente. Depois que trabalhei no projeto, esse problema desapareceu. Antes de fazer isso, tentei limpar a solução e garantir que nenhum dos projetos fosse assinado.

espero que ajude alguém ...

Se houver uma incompatibilidade de dependências, vá para o gerenciador de pacotes NuGet no nível da solução e verifique as guias Atualizar e Consolidar, harmonize tudo.

Eu recentemente atingi esse problema. No meu caso, eu tenho pacotes NuGet em diferentes montagens. O que eu tinha eram versões diferentes dos mesmos pacotes NuGet associados aos meus próprios assemblies.
Minha solução foi usar o gerenciador de pacotes NuGet na solução, em oposição aos projetos individuais. Isso permite uma opção de "consolidação", na qual você pode atualizar os pacotes do NuGet em quantos projetos quiser - para que todos façam referência à mesma versão do assembly. Quando fiz as consolidações, a falha na compilação desapareceu.

Também me deparei com esse tipo de problema, tudo o que eu precisava fazer era excluir o arquivo .dll (encontrado na referência) que está causando o erro e adicioná-lo novamente .

Funciona como um encanto.

Tente com update-package -reinstall -ignoredependencies

Basta ir em Publicar -> Arquivo de aplicativo -> E alterar o status de publicação da DLL afetada do pré-requisito para incluir! Isso funcionou para mim!