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

266

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?

Sergey Kucher
la source
72
En tant qu'essai rapide, supprimez les dossiers binet objde votre projet, puis générez à nouveau le projet. Parfois, cela fonctionne.
Jason Evans
signez-vous l'assemblée?
Felice Pollano
3
@Jason, Le nettoyage du projet et la reconstruction ont fonctionné pour moi. Je venais de signer les assemblées et le projet allait se construire, mais je ne le publierais pas.
Kratz
1
@Kratz - Heureux que cette astuce ait fonctionné pour vous :) C'est un peu comme réparer votre ordinateur en le redémarrant!
Jason Evans
Cela m'est arrivé lorsque le gestionnaire de configuration a réinitialisé les paramètres de génération de plusieurs de mes projets (c'est-à-dire qu'ils n'étaient pas configurés pour s'appuyer sur "Reconstruire tout"), après la version de ces projets et la reconstruction, l'erreur se produirait.
Alan

Réponses:

239

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.

Trousse
la source
7
Voici quelques informations supplémentaires: social.msdn.microsoft.com/Forums/en/csharplanguage/thread/… . En outre, la suppression de bin et obj et (si vous êtes sous votre contrôle) la définition de la version de l'assembly à la même valeur (par exemple, en laissant le numéro de build zéro) aide.
Kit
3
J'ai ajouté un peu à la fin de votre réponse pour refléter ma propre expérience aujourd'hui avec NuGet et cette même erreur. J'espère que cela aidera quelqu'un à un moment donné (peut-être même moi-même dans quelques mois!).
Neil Barnwell
2
Cette erreur continue d'apparaître pour moi et de supprimer le nom de l'assembly du fichier .csproj, puis le nettoyage l'a toujours corrigé pour moi. Merci!
ScubaSteve
1
Vous voudrez peut-être voir cette réponse si la réponse ci-dessus n'a pas fonctionné et que vous pensez avoir ajouté la référence NuGet à l'un de vos projets à l'aide d'Intellisense / ReSharper.
David Murdoch
La solution contient 4 projets. Un projet B est la bibliothèque de classes. La DLL de B était référencée dans les trois autres. Les deux autres projets de ( C et D ) sont exécutable référencé dans A . J'ai donc construit A et j'ai eu le même problème. Le correctif consistait à reconstruire le reste de deux projets en premier. Et puis projet de reconstruction Un problème résolu.
Vikram Singh Saini
268

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

CharleZ
la source
2
Ne fonctionnait pas pour moi dans VS2012 (la case à cocher est cochée de nouveau automatiquement lors de la publication). J'ai utilisé cette réponse à la place, car la DLL n'était nécessaire que pour le processus de génération. stackoverflow.com/a/8123074/17713
Matthias Meid
3
Lorsque vous utilisez ClickOnce, cette case à cocher est automatiquement activée à chaque publication de l'application avec l'assistant de publication. Voir msdn.microsoft.com/en-us/library/1sfbfyk0.aspx pour plus d'informations.
David Murdoch
8
J'ai MSVS 2015 et je ne vois pas l'onglet de sécurité sous les propriétés du projet
zeta
70

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

Otiel
la source
2
Le projet de module complémentaire exel n'a pas de bouton Fichiers d'application. stackoverflow.com/questions/6378801/…
Sergey Kucher
@SergeyKucher: Je ne le savais pas. Merci pour la mise à jour. Comme votre question ne précise pas que c'est pour un complément Excel, je pense que ma réponse est toujours valide ici (j'ai eu le même message d'erreur sur un projet winforms et l' ai résolu de cette façon).
Otiel
J'ai un projet Winforms qui a bien fonctionné jusqu'à ce que j'utilise l'assistant de publication, après quoi j'ai eu les erreurs de l'OP. La modification du statut de publication a résolu le problème. Merci
Kristian
7
Dans mon cas, ce problème a été résolu en changeant le statut de publication de INCLUDE (auto) à INCLUDE. Quoi qu'il en soit, votre réponse a aidé à ne pas insister sur les valeurs affichées. Merci beaucoup
Julio Nobre
22

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.

daniel
la source
13

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.

Sogger
la source
1
Ou tout simplement 'Clean Solution'
Unsliced
Un «Reconstruire tout» effectue d'abord un nettoyage et équivaut à «nettoyer» puis à «construire». Il est bon de noter cependant que, parfois, lorsque des fichiers ont été copiés manuellement ou copiés avec des horodatages différents, la fonctionnalité `` nettoyer '' / `` reconstruire '' ne résout pas le problème et il est nécessaire de supprimer manuellement les dossiers `` bin '' et `` obj ''.
Sogger
Pour ce problème lié à Excel, la suppression des dossiers bin / obj a fonctionné pour moi, les autres approches ne l'ont pas fait.
William Melani
6

vous devez signer l'assemblage avec une clé. Allez dans les propriétés du projet sous l'onglet signature: entrez la description de l'image ici

Felice Pollano
la source
6

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.

Nick Gotch
la source
6

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

Kishore
la source
6

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.

David Murdoch
la source
Oui, évitez d'utiliser Resharper pour ajouter des références. Resharper prendra la DLL de référence du dossier de débogage (ou de libération si vous êtes en mode de libération). Cela causera beaucoup de problèmes, en particulier dans les grands projets.
cepriego
5

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

Build -> Reconstruire la solution

Nathan
la source
4

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
RagtimeWilly
la source
4

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

ChrisO
la source
4

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.

Jimmy
la source
4

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

FunctorSalad
la source
2
Pour ajouter à cela, une manière légèrement plus douce de résoudre le problème consiste à copier la section <Target Name = "VisualStudioForApplicationsBuild"> entière du fichier situé au point 3 (c'est-à-dire: il suffit de trouver le fichier, de ne pas le copier et de le renommer) , dans le fichier proj de votre propre projet. ** et apportez la même modification que celle décrite au point 4. Cela remplacera le comportement uniquement pour votre projet et n'affectera alors rien d'autre sur votre machine. S'il y a des modifications dans le fichier d'origine dans une future mise à jour VS, vous devrez peut-être répéter le processus.
Adam
3

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

Arseni Mourzenko
la source
Je n'ai pas signé le * .dll, mais il n'y avait aucun problème auparavant (je n'ai pas eu l'erreur de compilation auparavant). La DLL référencée dans l'un des projets référencés de la publication, j'ai trouvé une solution laide pour référencer la DLL directement à partir du projet publié, pouvez-vous me dire pourquoi cela fonctionne maintenant? Ou comment pourrais-je résoudre le problème de manière opther? Merci
Sergey Kucher
1
@ user520535: eh bien, si vous n'avez pas signé la bibliothèque auparavant, vous devriez. Ce n'est pas le seul moyen pour cette bibliothèque de pouvoir être utilisée par des assemblys signés (un assemblage signé ne peut pas appeler un assemblage non signé), mais travailler avec des assemblys non signés est également très difficile lorsque vous traitez avec des plug-ins / ajout -en. Maintenant, pourquoi cela a commencé à causer des problèmes maintenant et pas avant? Je n'en ai aucune idée.
Arseni Mourzenko
@ user520535: si cela a aidé, vous êtes libre d'accepter ou de voter en faveur de la réponse.
Arseni Mourzenko
3

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.
Technologie
la source
3

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.

Hoang Ha
la source
2

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.

Minny
la source
2

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.

Huy Nguyen
la source
1

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

PatFromCanada
la source
1

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

Artexias
la source
0

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

Greg
la source
0

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.

Luke Puplett
la source
0

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.

Simon Miller
la source
0

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.

FritsJ
la source
0

Essayez avec update-package -reinstall -ignoredependencies

Stella Oliveira
la source
0

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!

SWIK
la source