Pourquoi est-ce que je reçois 'Assemblée' * .dll 'doit être signé en force pour être marqué comme condition préalable.'?
J'essaie de compiler mon complément Excel à l'aide de C # 4.0 et je commence à avoir 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 causer cela?
Mon hypothèse est que vous ne travaillez pas avec des assemblys nommés de manière forte. 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 solution dans mon cas était de supprimer la clé et les informations de version du nom de l’Assembly dans les fichiers .csproj (peu importe de toute façon), puis de procéder à une nouvelle génération.
Les modifications entre les différentes versions d’Assembly étaient compatibles avec les parties de la solution les concernant. Si ce n'est pas le cas chez vous, vous devrez peut-être effectuer un travail supplémentaire pour résoudre le problème.
NuGet
Avec NuGet, il est facile d'entrer dans cette situation si:
- Vous installez un package pour un projet dans votre solution.
- Une nouvelle version de ce package est déployée sur la source du package.
- Vous l'installez dans un autre projet de 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 qu'il s'agit d'une application ClickOnce, vous verrez ce problème.
Pour résoudre ce problème, lancez la commande update-package [package name] sur la console Nuget Package Manager afin de tout mettre sur un pied d’égalité, après quoi le problème disparaîtra.
Vous devez gérer les packages NuGet au niveau de la solution plutôt qu'au niveau du projet, à moins d'une raison impérieuse de ne pas le faire. La gestion des packages au niveau solution évite le potentiel de plusieurs versions de dépendances. Lorsque vous utilisez l'interface utilisateur de gestion, si l'onglet Consolidated indique qu'un ou plusieurs packages ont plusieurs versions, envisagez de les consolider en une seule.
Lorsque j'ai eu ce problème, j'ai résolu le problème en désactivant l'option "Activer les paramètres de sécurité ClickOnce".
Menu: Projet | 'Nom du projet' Propriétés ... | Onglet Sécurité | Case à cocher «Activer les paramètres de sécurité ClickOnce».
Voir cette réponse .
Allez à 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 marqué "Inclure" plutôt que "Prérequis".
Aller à la page de propriétés du projet. Ensuite, allez dans «Publier», puis dans «Fichiers d'application». Les dll mentionnées dans l'erreur seront marquées ici comme prérequis. Changez-les en 'Inclure'
J'ai eu ce problème. C'est arrivé parce que de nombreux projets pointaient 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é votre version d'Assembly ou copié une version différente de la bibliothèque gérée indiquée dans l'erreur, vous avez peut-être également déjà compilé des fichiers faisant référence à la mauvaise version. Un 'Rebuild All' (ou en vous supprimant 'bin et' obj 'dossiers comme mentionné dans un commentaire précédent) devrait résoudre ce cas.
Supprimer la DLL (où l'erreur s'est produite) et reconstruire la solution a résolu mon problème. Merci
Ajouter ma solution à ce problème pour qui que ce soit pourrait aider.
J'ai eu une solution ClickOnce jetant cette erreur. L'application faisait référence à un dossier "Libs" commun et contenait une référence de projet à un Foo.dll. Bien qu'aucun projet de la solution ne fasse référence à la copie statique du Foo.dll dans le dossier "Libs", certaines références de ce dossier le faisaient (c'est-à-dire: ma solution avait des références à Libs\Bar.dll qui référencaient Foo.dll.) les dépendances de Libs ainsi que leurs dépendances, les deux copies entraient dans le projet. Cela générait l'erreur ci-dessus.
J'ai résolu le problème en déplaçant ma version Libs\Foo.dll statique dans un sous-dossier, Libs\Fix\Foo.dll. Cette modification a obligé l'application ClickOnce à n'utiliser que la version du projet DLL et l'erreur a disparu.
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 importer 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 paquet NuGet via NuGet Package Manager (ou CLI).
... vous pouvez avoir des versions distinctes des packages NuGet DLL 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, de sorte que le NuGet processus de mise à jour ne le trouvera pas ou ne le mettra pas à 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 expliqué dans cette réponse )
Conseil Life Pro:
Ce problème peut survenir chaque fois que ReSharper/Intellisense suggère d’ajouter une référence à votre projet. Cela peut être beaucoup plus compliqué que l'exemple ci-dessus, avec de multiples projets imbriqués et des dépendances rendant la recherche difficile. Si la référence suggérée par ReSharper/Intellisense provient d’un package NuGet, utilisez NuGet pour l’installer.
vous devez signer l’Assemblée avec une clé. Allez dans les propriétés du projet sous l'onglet signature: 
Lorsque cela m'est arrivé avec le WindowsAPICodePack après l'avoir mis à jour, je viens de reconstruire la solution.
Construire -> Solution de reconstruction
Le déchargement et le rechargement du projet problème le résolvaient pour moi.
Il y avait trop de projets dans ma solution pour pouvoir être mis à jour individuellement, j'ai donc résolu le problème en:
- Cliquez avec le bouton droit sur ma solution et sélectionnez "Gérer les packages NuGet pour la solution ...".
- Aller à l'onglet Mises à jour
- Trouver le paquet affecté et sélectionner Mettre à jour
- Cliqué sur OK et cela a mis à jour toutes les instances du paquet
Votre assemblée est-elle bien signée?
Pour vérifier cela, appuyez sur Alt + Entrée sur votre projet (ou cliquez à droite, puis sur Propriétés). Allez à "Signing". Vérifiez que la case à cocher "Signer l'assemblage" est cochée, que le fichier de clé de nom fort est sélectionné et que "Signature différée uniquement" est décoché .
Je suis allé à publier , les fichiers de l'application, j'ai trouvé la DLL provoquant l'erreur qui a été modifiée en "Inclure" de "Inclure (Auto)". Je peux maintenant publier.
Cela est dû lorsque vous modifiez la version du fichier .dll qui est référencé. Vous devez supprimer tous les éléments ou le fichier .dll du dossier de construction cible.
Maintenant, voici 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 non disponible et sélectionnez l'option "Modifier".
Faites défiler jusqu'à la balise '<ItemGroup>' qui contient toutes les balises de ressources.
Maintenant, allez à la référence qui a été affichée sur la liste d’erreurs, vous remarquerez qu’elle utilise une seule balise (c.-à-d.
< Reference Include="assemble_name_here, Version=0.0.0.0, Culture=neutral" / >).Changez cela pour ressembler à 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 à nouveau avec le bouton droit de la souris sur le projet non disponible, cliquez sur l’option 'Recharger le projet', puis générez.
J'ai eu la même erreur de compilation. Une fois que j'ai ajouté le projet dépendant du fichier dll à la solution, le problème a été résolu.
J'ai rencontré ce problème après avoir migré un complément Excel à partir de packages.config vers PackageReference. Semble être lié à ce problème .
La solution suivante fonctionne comme une solution de contournement brute si vous n'utilisez pas ClickOnce (toutes les informations de dépendance du fichier .manifest seront omises):
- Décharger le projet, éditer .csproj
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)' != ''" />Modifiez une copie renommée du fichier
.targetsréférencé (dans mon cas, le fichier a été résolu enC:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targetset j'ai créé une copieMicrosoft.VisualStudio.Tools.Office_FIX.targetsdans le même dossier - n'a pas vérifié si cela fonctionnait dans un autre dossier).Recherchez l'élément
GenerateApplicationManifestet remplacez son attributDependencies="@(DependenciesForGam)"parDependencies="".Modifiez la section trouvée dans 2. afin de référencer votre fichier
.targetsmodifié à la place.
Cela devra être répété chaque fois que la version du fichier .targets fourni avec VS sera mise à jour (ou vous n'obtiendrez pas les mises à jour), mais j'espère que cela sera corrigé bientôt ...
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 Assembly à un 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 par vue dans la fenêtre du navigateur d’objets (menu Affichage-> Navigateur 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 une référence à ce projet de bibliothèque.
Ce qui m'a aidé, c'est que je suis allé sur Package Manager Solution et que j'ai examiné le package installé à l'origine du problème. J'ai vu que plusieurs projets référençaient le même package mais des versions différentes. Je les ai alignés en fonction de mes besoins et cela a fonctionné.
Après avoir essayé la plupart des solutions ici, j'ai finalement ajouté une référence au projet clic par clic, qui a été remplacé par Inclure (Auto) à partir de Include et a finalement fonctionné.
Essayez avec update-package -reinstall -ignoredependencies
En cas d'incompatibilité entre dépendances, accédez au gestionnaire de paquets de NuGet au niveau de la solution et vérifiez les onglets Mettre à jour et consolider, harmonisez tout.
Je tombe aussi dans le genre de problème, tout ce que je venais de faire est supprime le .dll (peut être trouvé dans la référence) qui cause l’erreur et ajoute le encore
Fonctionne comme un charme.
J'ai récemment frappé ce problème. Dans mon cas, j'ai des paquets NuGet sur différents assemblys. Ce que j'avais était 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 active une option de "consolidation", dans laquelle vous pouvez mettre à jour vos paquets NuGet sur autant de projets que vous le souhaitez - ils font donc tous référence à la même version de Assembly . Lorsque j'ai effectué les consolidations, l'échec de la construction a disparu.
J'ai eu cela dans une solution avec 6 projets. Un de mes projets faisait référence à l’assemblée nommée 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 a été de supprimer l’assemblée nommée où qu’elle se trouve et de la rajouter. Une fois que j'ai travaillé sur le projet, ce problème a disparu. Avant cela, j’essayais de nettoyer la solution et de veiller à ce qu’aucun des projets ne soit signé.
j'espère que ça aide quelqu'un ...