Warum bekomme ich 'Assembly' * .dll 'muss stark signiert sein, um als Voraussetzung markiert zu werden.'?

Ich versuche, mein Excel-Add-In mit C # 4.0 zu kompilieren, und habe dieses Problem beim Erstellen meines Projekts in Visual Studio festgestellt. Es ist wichtig, Ihnen zu sagen, dass ich dieses Problem noch nie hatte. Was könnte dazu führen?

Ich vermute, dass Sie nicht mit stark benannten Assemblys arbeiten. Ich hatte diesen Fehler, wenn zwei Projekte auf leicht unterschiedliche Versionen derselben Assembly verweisen und ein abhängigeres Projekt auf diese Projekte verweist. In meinem Fall bestand die Lösung darin, die Schlüssel- und Versionsinformationen aus dem Assemblynamen in den .csproj-Dateien zu entfernen (es war sowieso egal) und dann einen sauberen Build durchzuführen.

Änderungen zwischen den verschiedenen Baugruppenversionen waren mit den darauf bezogenen Teilen der Lösung kompatibel. Wenn dies bei Ihnen nicht der Fall ist, müssen Sie möglicherweise weitere Arbeiten ausführen, um das Problem zu beheben.

NuGet

Mit NuGet ist es einfach, in diese Situation zu geraten, wenn:

1. Sie installieren ein Paket für ein Projekt in Ihrer Lösung.
2. Eine neue Version dieses Pakets wird für die Paketquelle bereitgestellt.
3. Sie installieren es in einem anderen Projekt in derselben Lösung.

Dies führt zu zwei Projekten in Ihrer Lösung, die auf verschiedene Versionen der Assemblys dieses Pakets verweisen. Wenn einer von ihnen auf den anderen verweist und eine ClickOnce-App ist, wird dieses Problem angezeigt.

Um dies zu beheben, geben Sie den update-package [package name]Befehl in der Nuget Package Manager-Konsole ein, um alles auf gleiche Wettbewerbsbedingungen zu bringen. An diesem Punkt verschwindet das Problem.

Sie sollten NuGet-Pakete eher auf Lösungsebene als auf Projektebene verwalten, es sei denn, es gibt einen zwingenden Grund, dies nicht zu tun. Die Paketverwaltung auf Lösungsebene vermeidet das Potenzial mehrerer Versionen von Abhängigkeiten. Wenn bei Verwendung der Verwaltungsbenutzeroberfläche auf der Registerkarte " Konsolidiert" ein oder mehrere Pakete mit mehreren Versionen angezeigt werden, sollten Sie sie auf eine konsolidieren.

Als ich dieses Problem hatte, habe ich es behoben, indem ich die "ClickOnce-Sicherheitseinstellungen aktivieren" deaktiviert habe.

Menü: Projekt | Eigenschaften 'Projektname' ... | Registerkarte Sicherheit | Kontrollkästchen "ClickOnce-Sicherheitseinstellungen aktivieren".

Siehe diese Antwort .

Gehen Sie zur Veröffentlichungsseite und klicken Sie auf "Anwendungsdateien". Von dort sollten Sie eine Liste Ihrer DLLs sehen. Stellen Sie sicher, dass für diejenigen, die Ihnen Probleme bereiten, der Veröffentlichungsstatus als "Einschließen" und nicht als "Voraussetzung" markiert ist.

Ich habe dieses Problem gehabt. Es geschah, weil ich viele Projekte hatte, die auf dieselbe Baugruppe zeigten, aber aus verschiedenen Versionen. Ich löse es, indem ich für alle Projekte in meiner Lösung dieselbe Version auswähle.

Wenn Sie Ihre Assemblyversion geändert oder eine andere Version der im Fehler angegebenen verwalteten Bibliothek kopiert haben, haben Sie möglicherweise auch zuvor Dateien kompiliert, die auf die falsche Version verweisen. Ein "Alle neu erstellen" (oder das Löschen Ihrer Ordner "bin" und "obj", wie in einem früheren Kommentar erwähnt) sollte diesen Fall beheben.

Sie müssen die Baugruppe mit einem Schlüssel signieren. Gehen Sie in die Projekteigenschaften unter der Registerkarte Signieren:

Das Hinzufügen meiner Lösung für dieses Problem für jeden, dem es helfen könnte.

Ich hatte eine ClickOnce-Lösung, die diesen Fehler auslöste. Die App verwies auf einen gemeinsamen "Libs" -Ordner und enthielt einen Projektverweis auf a Foo.dll. Während keines der Projekte in der Lösung auf die statische Kopie des Foo.dllOrdners im Ordner "Libs" verwies, war dies bei einigen Verweisen in diesem Ordner der Fall (dh: Meine Lösung hatte Libs\Bar.dllVerweise, auf die verwiesen wurde Foo.dll). Da die CO-App alle Abhängigkeiten abgerufen hat LibsBeide Kopien gingen neben ihren Abhängigkeiten in das Projekt ein. Dies erzeugte den obigen Fehler.

Ich habe das Problem behoben, indem ich meine Libs\Foo.dllstatische Version in einen Unterordner verschoben habe Libs\Fix\Foo.dll. Durch diese Änderung verwendete die ClickOnce-App nur die Projektversion der DLL und der Fehler verschwand.

Das Löschen der DLL (wo der Fehler aufgetreten ist) und das Neuerstellen der Lösung haben mein Problem behoben. Vielen Dank

Wenn Sie alle anderen Antworten in dieser Frage ausprobiert haben und Sie:

• Haben Sie mehrere Projekte in Ihrer Lösung
• Haben Sie ein Projekt (Projekt A), das auf ein anderes Projekt (Projekt B) verweist, dessen Projekt auf ein NuGet-Paket verweist.
• In Projekt A haben Sie Intellisense / ReSharper verwendet, um den Verweis auf das in Projekt B referenzierte NuGet-Paket einzufügen (dies kann passieren, wenn eine Methode in Projekt B einen vom NuGet-Paket bereitgestellten Typ zurückgibt und diese Methode in Projekt A verwendet wird).
• Das NuGet-Paket wurde über NuGet Package Manager (oder CLI) aktualisiert.

... Sie haben möglicherweise separate Versionen der NuGet-Paket-DLL in Ihren Projektreferenzen, da die von Intellisense / ReSharper erstellte Referenz eine "normale" Referenz ist und nicht wie erwartet eine NuGet-Referenz, sodass der NuGet-Aktualisierungsprozess gewonnen hat. t finde oder aktualisiere es!

Um dies zu beheben, entfernen Sie den Verweis in Projekt A, installieren Sie ihn mit NuGet und stellen Sie sicher, dass die NuGet-Pakete in allen Projekten dieselbe Version haben. (wie in dieser Antwort erklärt )

Life Pro-Tipp:

Dieses Problem kann auftreten, wenn ReSharper / Intellisense vorschlägt, einen Verweis auf Ihr Projekt hinzuzufügen. Es kann viel komplizierter sein als das obige Beispiel, da mehrere miteinander verwobene Projekte und Abhängigkeiten es schwierig machen, es aufzuspüren. Wenn die von ReSharper / Intellisense vorgeschlagene Referenz tatsächlich aus einem NuGet-Paket stammt, installieren Sie sie mit NuGet.

Als mir dies mit dem WindowsAPICodePack nach der Aktualisierung passiert ist, habe ich die Lösung neu erstellt.

Build -> Lösung neu erstellen

Meine Lösung enthielt zu viele Projekte, um sie einzeln zu aktualisieren. Daher habe ich Folgendes behoben:

• Klicken Sie mit der rechten Maustaste auf meine Lösung und wählen Sie "NuGet-Pakete für Lösung verwalten ...".
• Wechseln Sie zur Registerkarte Updates
• Suchen Sie das betroffene Paket und wählen Sie Aktualisieren
• Klicken Sie auf OK, um alle Instanzen des Pakets auf den neuesten Stand zu bringen

Das Entladen und Neuladen des Problemprojekts hat es für mich gelöst.

Ich ging zum Veröffentlichen , Anwendungsdateien, fand die DLL, die den Fehler auslöste, änderte sie in "Einschließen" von "Einschließen (Auto)". Ich kann jetzt veröffentlichen.

Ich bin auf dieses Problem gestoßen, nachdem ich ein Excel-Add-In von packages.config nach PackageReference migriert habe. Scheint mit diesem Problem verbunden zu sein .

Folgendes funktioniert als grobe Problemumgehung, wenn Sie ClickOnce nicht verwenden (es werden alle Abhängigkeitsinformationen aus der .manifestDatei weggelassen):

1. Projekt entladen, .csproj bearbeiten

2. Finden Sie den Abschnitt, der so aussieht:

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

3. Bearbeiten Sie eine umbenannte Kopie der referenzierten .targetsDatei (in meinem Fall wurde die Datei aufgelöst C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targetsund ich habe eine Kopie Microsoft.VisualStudio.Tools.Office_FIX.targetsim selben Ordner erstellt - habe nicht überprüft, ob sie aus einem anderen Ordner funktioniert).

4. Suchen Sie das GenerateApplicationManifestElement und ändern Sie sein Attribut Dependencies="@(DependenciesForGam)"in Dependencies="".

5. Ändern Sie den Abschnitt in 2., um .targetsstattdessen auf Ihre bearbeitete Datei zu verweisen .

Dies muss wiederholt werden, wenn die .targetsmit VS gelieferte Version der Datei aktualisiert wird (oder Sie die Updates nicht erhalten), aber ich hoffe, dass sie bald behoben wird ...

Ist Ihre Baugruppe ordnungsgemäß signiert?

Um dies zu überprüfen, drücken Sie Alt + Eingabetaste in Ihrem Projekt (oder klicken Sie mit der rechten Maustaste und dann auf Eigenschaften). Gehen Sie zu "Signieren". Stellen Sie sicher, dass das Kontrollkästchen "Baugruppe signieren" aktiviert und die Schlüsseldatei für den starken Namen ausgewählt und "Nur Verzögerungszeichen" deaktiviert ist .

Hier ist eine andere Herangehensweise an das Problem:

• Klicken Sie mit der rechten Maustaste auf das Projekt und wählen Sie die Option "Projekt entladen". Sie werden feststellen, dass Ihr Projekt nicht mehr verfügbar ist.

• Klicken Sie mit der rechten Maustaste auf das nicht verfügbare Projekt und wählen Sie die Option "Bearbeiten".

• Scrollen Sie nach unten zum Tag '<ItemGroup>', das alle Ressourcen-Tags enthält.

• Gehen Sie nun zu der Referenz, die in der Fehlerliste angezeigt wurde. Sie werden feststellen, dass ein einzelnes Tag (dh < Reference Include="assemble_name_here, Version=0.0.0.0, Culture=neutral" / >) verwendet wird.

• Ändern Sie dies wie folgt:

.

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

• Speichern Sie Ihre Änderungen. Klicken Sie erneut mit der rechten Maustaste auf das nicht verfügbare Projekt und klicken Sie auf die Option "Projekt neu laden". Erstellen Sie dann.

Dies wird verursacht, wenn Sie die Version der DLL ändern, auf die verwiesen wird. Sie müssen alle Elemente oder die DLL im Zielerstellungsordner löschen.

Ich habe den ähnlichen Compilerfehler. Sobald ich das abhängige Projekt der DLL-Datei zur Lösung hinzugefügt habe, ist das Problem behoben.

Wenn Ihr Hauptprojekt einige Bibliotheksprojekte verwendet und auf diese verweist, können Sie dieses Problem verursachen, wenn Ihr Projekt auf eine Assembly-DLL-Datei anstatt auf ein Bibliotheksprojekt verweist, wenn Sie etwas in Ihrem Bibliotheksprojekt ändern (z. B. eine Klasse umbenennen).

Sie können alle Verweise auf Ihr Hauptprojekt anhand der Ansicht im Objektbrowser-Fenster (Menü Ansicht-> Objektbrowser) überprüfen. Ein Verweis auf eine DLL-Datei hat immer eine Versionsnummer. Beispiel: TestLib [1.0.0.0]

Lösung: Löschen Sie die aktuelle Referenz Ihres Hauptprojekts zum Bibliotheksprojekt und fügen Sie erneut eine Referenz zu diesem Bibliotheksprojekt hinzu.

Nachdem ich die meisten Lösungen hier ausprobiert hatte, fügte ich schließlich einen Verweis auf das Projekt aus dem Click-Once-Projekt hinzu. Dies änderte es in Include (Auto) von Include und es funktionierte schließlich.

Was mir geholfen hat, war, dass ich zu Package Manager Solution gegangen bin und mir das installierte Paket angesehen habe, das das Problem verursacht hat. Ich habe gesehen, dass mehrere Projekte auf dasselbe Paket, aber unterschiedliche Versionen verweisen. Ich habe sie nach meinen Bedürfnissen ausgerichtet und es hat funktioniert.

Ich hatte dies in einer Lösung mit 6 Projekten. Eines meiner Projekte bezog sich auf die benannte Assembly als Dateireferenz. Die anderen zeigten alle auf die Projektreferenz.

In diesen Fällen wird normalerweise ein anderer Fehler angezeigt.

Meine Lösung bestand darin, die benannte Assembly an einer beliebigen Stelle zu löschen und wieder hinzuzufügen. Nachdem ich das Projekt durchgearbeitet hatte, verschwand dieses Problem. Vorher habe ich versucht, die Lösung zu reinigen und sicherzustellen, dass keines der Projekte unterzeichnet wurde.

hoffe es hilft jemandem ...

Wenn die Abhängigkeiten nicht übereinstimmen, rufen Sie den NuGet-Paketmanager auf Lösungsebene auf, überprüfen Sie die Registerkarten Aktualisieren und Konsolidieren und harmonisieren Sie alles.

Ich bin kürzlich auf dieses Problem gestoßen. In meinem Fall habe ich NuGet-Pakete auf verschiedenen Baugruppen. Was ich hatte, waren verschiedene Versionen derselben NuGet-Pakete, die meinen eigenen Assemblys zugeordnet waren.
Meine Lösung bestand darin, den NuGet-Paketmanager für die Lösung zu verwenden, im Gegensatz zu den einzelnen Projekten. Dies ermöglicht eine "Konsolidierungs" -Option, bei der Sie Ihre NuGet-Pakete für beliebig viele Projekte aktualisieren können, sodass alle auf dieselbe Version der Assembly verweisen. Als ich die Konsolidierungen durchführte, verschwand der Build-Fehler.

Ich stoße auch auf ein Problem. Alles, was ich tun musste, ist die DLL ( siehe Referenz), die den Fehler verursacht, zu löschen und erneut hinzuzufügen .

Klappt wunderbar.

Versuchen Sie es mit update-package -reinstall -ignoredependencies

Gehen Sie einfach zu Veröffentlichen -> Anwendungsdatei -> und ändern Sie den Status der betroffenen DLL-Veröffentlichung von der Voraussetzung zum Einschließen! Das hat bei mir funktioniert!