Pourquoi est-ce que j'obtiens 'Assembly' * .dll 'doit être fort signé pour être marqué comme prérequis.'?

J'essaie de compiler mon complément Excel à l'aide de C # 4.0 et j'ai commencé à obtenir ce problème lors de la construction de mon projet dans Visual Studio. Il est important de vous dire que je n'ai jamais eu ce problème auparavant. Qu'est-ce qui pourrait provoquer cela?

Je suppose que vous ne travaillez pas avec des assemblys fortement nommés. J'ai eu cette erreur lorsque deux projets font référence à des versions légèrement différentes du même assemblage et qu'un projet plus dépendant fait référence à ces projets. Dans mon cas, la résolution consistait à supprimer les informations de clé et de version du nom de l'assembly dans les fichiers .csproj (cela n'avait pas d'importance de toute façon), puis à effectuer une nouvelle génération.

Les changements entre les différentes versions d'assemblage étaient compatibles avec les parties de la solution s'y référant. Si ce n'est pas le cas avec vous, vous devrez peut-être faire plus de travail pour résoudre le problème.

NuGet

Avec NuGet, il est facile de se retrouver dans cette situation si:

1. Vous installez un package sur un projet dans votre solution.
2. Une nouvelle version de ce package est déployée sur la source du package.
3. Vous l'installez sur un autre projet dans la même solution.

Il en résulte deux projets dans votre solution référençant différentes versions des assemblys de ce package. Si l'un d'eux fait référence à l'autre et est une application ClickOnce, vous verrez ce problème.

Pour résoudre ce problème, update-package [package name]exécutez la commande dans la console Nuget Package Manager pour tout mettre à niveau, à quel point le problème disparaît.

Vous devez gérer les packages NuGet au niveau de la solution plutôt qu'au niveau du projet, sauf s'il existe une raison impérieuse de ne pas le faire. La gestion des packages au niveau de la solution évite le potentiel de plusieurs versions de dépendances. Lorsque vous utilisez l'interface de gestion, si l' onglet Consolidated affiche 1 ou plusieurs packages ayant plusieurs versions, envisagez de les consolider en une seule.

Lorsque j'ai eu ce problème, je l'ai résolu en désactivant les «Activer les paramètres de sécurité ClickOnce».

Menu: Projet | Propriétés 'Nom du projet' ... | Onglet Sécurité | Case à cocher «Activer les paramètres de sécurité ClickOnce».

Voir cette réponse .

Accédez à la page de publication et cliquez sur "Fichiers d'application". De là, vous devriez voir une liste de vos DLL. Assurez-vous que ceux qui vous causent des problèmes ont leur état de publication marqué comme "Inclure" plutôt que "Prérequis".

J'ai eu ce problème. C'est arrivé parce que j'avais de nombreux projets pointant vers le même assemblage mais à partir de versions différentes. Je le résous en sélectionnant la même version pour tous les projets de ma solution.

Si vous avez modifié la version de votre assembly ou copié une version différente de la bibliothèque gérée indiquée dans l'erreur, vous pouvez également avoir précédemment compilé des fichiers référençant la mauvaise version. Un 'Reconstruire tout' (ou supprimer vos dossiers 'bin et' obj 'comme mentionné dans un commentaire précédent) devrait résoudre ce cas.

vous devez signer l'assemblage avec une clé. Allez dans les propriétés du projet sous l'onglet signature:

Ajouter ma solution pour ce problème à tous ceux qui pourraient l'aider.

J'ai eu une solution ClickOnce lançant cette erreur. L'application faisait référence à un dossier "Libs" commun et contenait une référence de projet à a Foo.dll. Bien qu'aucun des projets de la solution Foo.dllne fasse référence à la copie statique du dans le dossier "Libs", certaines des références de ce dossier le faisaient (c.-à-d. Ma solution avait des références Libs\Bar.dllauxquelles elle faisait référence Foo.dll). Puisque l'application CO a extrait toutes les dépendances de Libsainsi que leurs dépendances, les deux copies entraient dans le projet. Cela générait l'erreur ci-dessus.

Je fixe le problème en déplaçant ma Libs\Foo.dllversion statique dans un sous - dossier, Libs\Fix\Foo.dll. Cette modification a fait que l'application ClickOnce utilise uniquement la version de projet de la DLL et l'erreur a disparu.

La suppression de la DLL (où l'erreur s'est produite) et la reconstruction de la solution ont résolu mon problème. Merci

Si vous avez essayé toutes les autres réponses dans cette question et que vous:

• Avoir plusieurs projets dans votre solution
• Avoir un projet (projet A) qui fait référence à un autre projet (projet B), dont le projet fait référence à un package NuGet.
• Dans le projet A, vous avez utilisé Intellisense / ReSharper pour introduire la référence au package NuGet référencé dans le projet B (cela peut se produire lorsqu'une méthode du projet B renvoie un type fourni par le package NuGet et que cette méthode est utilisée dans le projet A)
• a mis à jour le package NuGet via NuGet Package Manager (ou CLI).

... vous pouvez avoir des versions distinctes de la DLL des packages NuGet dans les références de vos projets, car la référence créée par Intellisense / ReSharper sera une référence "normale" et non une référence NuGet comme prévu, donc le processus de mise à jour NuGet a gagné ' t le trouver ou le mettre à jour!

Pour résoudre ce problème, supprimez la référence dans le projet A, puis utilisez NuGet pour l'installer et assurez-vous que les packages NuGet dans tous les projets sont la même version. (comme expliqué dans cette réponse )

Astuce Life Pro:

Ce problème peut survenir chaque fois que ReSharper / Intellisense suggère d'ajouter une référence à votre projet. Il peut être beaucoup plus compliqué que l'exemple ci-dessus, avec plusieurs projets et dépendances imbriqués, ce qui rend la recherche difficile. Si la référence suggérée par ReSharper / Intellisense provient en fait d'un package NuGet, utilisez NuGet pour l'installer.

Lorsque cela m'est arrivé avec WindowsAPICodePack après l'avoir mis à jour, je viens de reconstruire la solution.

Build -> Reconstruire la solution

Il y avait trop de projets dans ma solution à parcourir et à mettre à jour individuellement, j'ai donc corrigé cela en:

• Cliquer avec le bouton droit sur ma solution et sélectionner «Gérer les packages NuGet pour la solution ...»
• Accéder à l'onglet Mises à jour
• Trouver le package concerné et sélectionner Mettre à jour
• Cliquez sur OK et cela a mis à jour toutes les instances du package

Décharger et recharger le projet problématique l'a résolu pour moi.

Je suis allé publier , les fichiers d'application, j'ai trouvé que la DLL lançant l'erreur l'a changé en «Inclure» de «Inclure (Auto)». Je peux maintenant publier.

J'ai rencontré ce problème après la migration d'un complément Excel de packages.config vers PackageReference. Semble être lié à ce problème .

Ce qui suit fonctionne comme une solution de contournement grossière si vous n'utilisez pas ClickOnce (il omettra toutes les informations de dépendance du .manifestfichier):

1. Décharger le projet, modifier .csproj

2. Trouvez la section qui ressemble à ceci:

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

3. Modifier une copie renommée du .targetsfichier référencé (dans mon cas, le fichier a été résolu C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targetset j'ai fait une copie Microsoft.VisualStudio.Tools.Office_FIX.targetsdans le même dossier - je n'ai pas vérifié si cela fonctionne à partir d'un dossier différent).

4. Recherchez l' GenerateApplicationManifestélément et changez son attribut Dependencies="@(DependenciesForGam)"en Dependencies="".

5. Modifiez la section trouvée en 2. pour référencer votre .targetsfichier édité à la place.

Cela devra être répété chaque fois que la version du .targetsfichier livré avec VS est mise à jour (ou vous n'obtiendrez pas les mises à jour), mais j'espère que ce sera bientôt corrigé ...

Votre assemblée est-elle correctement signée?

Pour vérifier cela, appuyez sur Alt + Entrée sur votre projet (ou cliquez avec le bouton droit, puis sur Propriétés). Allez dans "Signature". Vérifiez que la case à cocher "Signer l'assembly" est cochée et que le fichier de clé de nom fort est sélectionné et que "Signe de retard uniquement" n'est pas coché .

Voici maintenant une approche différente du problème:

• Faites un clic droit sur le projet et sélectionnez l'option «Décharger le projet». Vous remarquerez que votre projet devient indisponible.

• Cliquez avec le bouton droit sur le projet indisponible et sélectionnez l'option «Modifier».

• Faites défiler jusqu'à la balise «<ItemGroup>» qui contient toutes les balises de ressource.

• Maintenant, allez à la référence qui a été affichée sur la liste des erreurs, vous remarquerez qu'elle utilise une seule balise (ie < Reference Include="assemble_name_here, Version=0.0.0.0, Culture=neutral" / >).

• Modifiez cela pour qu'il ressemble à ceci:

.

<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 >

• Enregistrez vos modifications, cliquez de nouveau avec le bouton droit sur le projet indisponible et cliquez sur l'option «Recharger le projet», puis créez.

Cela est dû lorsque vous modifiez la version du .dll qui est référencé. Vous devez supprimer tous les éléments ou le fichier .dll dans le dossier de génération cible.

J'ai eu l'erreur de compilation similaire. Une fois que j'ajoute le projet dépendant du fichier dll à la solution, le problème est résolu.

Si votre projet principal utilise des projets de bibliothèque et y fait référence, vous pouvez provoquer ce problème si votre projet fait référence à un fichier dll d'assembly à la place au projet de bibliothèque lorsque vous modifiez quelque chose dans votre projet de bibliothèque (ex: renommer une classe).

Vous pouvez vérifier toutes les références à votre projet principal en les visualisant dans la fenêtre Explorateur d'objets (menu Affichage-> Explorateur d'objets). Une référence à un fichier dll a toujours un numéro de version. Ex: TestLib [1.0.0.0]

Solution: supprimez la référence actuelle de votre projet principal au projet de bibliothèque et ajoutez à nouveau la référence à ce projet de bibliothèque.

Après avoir essayé la plupart des solutions ici, j'ai finalement ajouté une référence au projet à partir du projet click once, cela l'a changé en Include (Auto) depuis Include et cela a finalement fonctionné.

Ce qui m'a aidé, c'est que je suis allé sur Package Manager Solution et j'ai regardé le package installé qui causait le problème. J'ai vu que plusieurs projets faisaient référence au même package mais à des versions différentes. Je les ai alignés en fonction de mes besoins et cela a fonctionné.

J'ai eu cela dans une solution avec 6 projets. L'un de mes projets faisait référence à l'assembly nommé en tant que référence de fichier. Les autres pointaient tous vers la référence du projet.

J'obtiens généralement une erreur différente dans ces cas.

Ma solution était de supprimer l'assembly nommé n'importe où il était référencé et de le rajouter. Une fois que j'ai travaillé sur le projet, ce problème a disparu. Avant de faire cela, j'ai essayé de nettoyer la solution et de m'assurer qu'aucun des projets n'était signé.

j'espère que ça aide quelqu'un ...

S'il s'agit d'une incompatibilité de dépendances, dépendez du gestionnaire de packages NuGet au niveau de la solution et vérifiez les onglets Mettre à jour et Consolider, harmonisez le tout.

J'ai récemment rencontré ce problème. Dans mon cas, j'ai des packages NuGet sur différents assemblys. Ce que j'avais, c'était différentes versions des mêmes packages NuGet associés à mes propres assemblys.
Ma solution était d'utiliser le gestionnaire de packages NuGet sur la solution, par opposition aux projets individuels. Cela permet une option de «consolidation», où vous pouvez mettre à niveau vos packages NuGet sur autant de projets que vous le souhaitez - afin qu'ils référencent tous la même version de l'assembly. Quand j'ai fait les consolidations, l'échec de la construction a disparu.

Je tombe également sur une sorte de problème, tout ce que j'avais à faire était de supprimer le fichier .dll (qui peut être trouvé en référence) qui provoquait l'erreur et de l' ajouter à nouveau .

Fonctionne comme un charme.

Essayez avec update-package -reinstall -ignoredependencies

Allez simplement dans Publier -> Fichier d'application -> Et changez le statut de publication de la DLL effectuée des prérequis pour l'inclure! Cela a fonctionné pour moi!