Pourquoi est-ce que je reçois le message ‘Assembly’ * .dll ‘doit être signé de manière à être marqué comme condition préalable’?

J’essaie de comstackr mon addel Excel avec C # 4.0 et j’ai commencé à avoir ce problème lors de la construction de mon projet dans Visual Studio. Il est important de vous dire que je n’ai pas 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. La résolution dans mon cas consistait à supprimer les informations de clé et de version du nom de l’assembly dans les fichiers .csproj (cela n’avait pas d’importance), puis à effectuer une nouvelle génération.

Dans mon cas, les changements entre les différentes versions d’assemblage étaient compatibles avec les parties de la solution les concernant. 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 d’entrer 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.

Cela se traduit par 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 moi, la solution consistait à lancer la commande update-package [package name] sur la console Nuget Package Manager, ce qui a permis de résoudre tous les problèmes et de résoudre le problème.

Lorsque j’ai eu ce problème, je l’ai corrigé en désactivant les parameters de sécurité “Activer ClickOnce”.

Menu: Projet | ‘Nom du projet’ Propriétés … | Onglet Sécurité | Case à cocher “Activer les parameters 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 le statut de publication de ceux qui vous posent problème est “Inclure” plutôt que “Prérequirejs”.

Accédez à la page des propriétés du projet. Ensuite, allez dans “Publier” puis “Fichiers d’application”. Les dll mentionnés dans l’erreur seront marqués comme prérequirejs. Changez-les en ‘Inclure’

J’ai eu ce problème. Cela est arrivé parce que beaucoup de projets indiquaient le même assemblage, mais des 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é votre version d’assemblage ou copié une version différente de la bibliothèque gérée indiquée dans l’erreur, vous avez peut-être déjà compilé des fichiers référençant la mauvaise version. Un ‘Rebuild All’ (ou la suppression de vos dossiers ‘bin et’ obj ‘comme mentionné dans un précédent commentaire) devrait résoudre ce problème.

L’ajout de ma solution à ce problème pourrait aider n’importe qui.

J’ai eu une solution ClickOnce en lançant cette erreur. L’application a référencé un dossier commun “Libs” et contenait une référence de projet à un Foo.dll . Bien qu’aucun des projets de la solution ne Foo.dll référence à la copie statique du Foo.dll dans le dossier «Libs», certaines des références de ce dossier (par exemple: ma solution Libs\Bar.dll qui Foo.dll référence à Foo.dll .) Puisque l’application CO a extrait toutes les dépendances des Libs et de leurs dépendances, les deux copies étaient intégrées au projet. Cela générait l’erreur ci-dessus.

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

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

vous devez signer l’assemblage avec une clé. Accédez aux propriétés du projet sous l’onglet signature: entrer la description de l'image ici

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

  • Avoir plusieurs projets dans votre solution
  • Avoir un projet (projet A) qui 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)
  • 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, 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 de tous les projets ont la même version. (comme l’explique cette réponse )


Life Pro Astuce:

Ce problème peut survenir chaque fois que ReSharper / Intellisense suggère d’append une référence à votre projet. Il peut être beaucoup plus compliqué que l’exemple ci-dessus, avec de multiples projets et dépendances nesteds qui rendent difficile le suivi. Si la référence suggérée par ReSharper / Intellisense provient en fait d’un package NuGet, utilisez NuGet pour l’installer.

Il y avait trop de projets dans ma solution pour passer en revue et mettre à jour individuellement, donc j’ai résolu ce problème en:

  • Cliquez avec le bouton droit de la souris sur ma solution et sélectionnez “Gérer les packages NuGet pour la solution …”
  • Aller à l’onglet Mises à jour
  • Recherche du package concerné et sélection de la mise à jour
  • Cliqué sur OK et cela a amené toutes les instances du package à jour

Le déchargement et le rechargement du projet de problème l’ont résolu pour moi.

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

Construire -> Reconstruire la solution

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 “Signing”. 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 “Retarder uniquement” n’est pas coché.

Maintenant, voici une approche différente du problème:

  • Cliquez avec le bouton 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 ‘‘ qui contient toutes les balises de ressources.

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

  • Changez cela pour ressembler à ceci:

.

  < Private > True < / Private > < HintPath > path_here\assemble_name_here.dll < / HintPath > < / Reference > 
  • Enregistrez vos modifications, cliquez à nouveau avec le bouton droit de la souris sur le projet indisponible et cliquez sur l’option «Recharger le projet», puis créez.

Cela se produit lorsque vous modifiez la version du fichier .dll 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’ai ajouté le projet dépendant du fichier dll à la solution, le problème a été 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 d’assembly dll plutôt qu’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 dans la fenêtre de l’explorateur d’objects (menu Affichage-> Navigateur d’objects). 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 dans le projet de bibliothèque et ajoutez à nouveau une référence à ce projet de bibliothèque.

Je suis allé à publier , les fichiers d’application, trouvé le dll jetant l’erreur a changé à «Inclure» de «Inclure (Auto)». Je peux maintenant publier.

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

Je reçois généralement une erreur différente dans ces cas.

Ma solution consistait à supprimer l’assembly nommé où il était référencé et à le rappend. Une fois que j’ai travaillé sur le projet, le problème a disparu. Avant 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 …

Après avoir essayé la plupart des solutions ici, j’ai finalement ajouté une référence au projet à partir du projet cliquez une fois, cela l’a changé pour inclure (Auto) from Include et cela a finalement fonctionné.

En cas d’incompatibilité de dépendances de dépendances, accédez au gestionnaire de packages NuGet au niveau de la solution et vérifiez les tabs Update et Consolidate, harmonisez tout.

J’ai récemment rencontré ce problème. Dans mon cas, j’ai des paquets NuGet sur différents assemblages. J’avais différentes versions des mêmes packages NuGet associés à mes propres assemblys.
Ma solution consistait à utiliser le gestionnaire de paquets NuGet sur la solution, par opposition aux projets individuels. Cela permet une option de «consolidation», dans laquelle 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’assemblage. Lorsque j’ai effectué les consolidations, l’échec de la construction a disparu.

Je me heurte également à une sorte de problème, il me suffit de supprimer le fichier .dll (qui peut être trouvé dans la référence) à l’origine de l’erreur et de l’ append à nouveau .

Fonctionne comme un charme.

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 brute si vous n’utilisez pas ClickOnce (il omettra toutes les informations de dépendance du fichier .manifest ):

  1. Décharger le projet, éditer .csproj
  2. Trouvez la section qui ressemble à ceci:

       
  3. Modifiez une copie renommée du fichier .targets référencé (dans mon cas, le fichier a été résolu en C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets et moi avons fait une copie Microsoft.VisualStudio.Tools.Office_FIX.targets dans le même dossier – n’a pas vérifié si cela fonctionne à partir d’un autre dossier).

  4. Recherchez l’élément GenerateApplicationManifest et modifiez son atsortingbut Dependencies="@(DependenciesForGam)" en Dependencies="" .

  5. Modifiez la section trouvée dans 2. pour référencer votre fichier .targets modifié à la place.

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