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

Als ich dieses Problem hatte, wurde es durch Deaktivieren der 'ClickOnce-Sicherheitseinstellungen aktivieren' behoben.

Menü: Projekt | 'Projektname' Eigenschaften ... | 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 der Veröffentlichungsstatus derjenigen, die Ihnen Probleme bereiten, als "Einschließen" und nicht als "Voraussetzung" gekennzeichnet ist.

Gehen Sie zur Eigenschaftsseite des Projekts. Gehen Sie dann zu "Veröffentlichen" und dann zu "Anwendungsdateien". Die im Fehler genannten DLLs werden dort als Voraussetzung markiert. Ändern Sie sie in "Include".

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

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

Durch das Löschen von DLL (wo der Fehler aufgetreten ist) und das Erstellen der Lösung wurde mein Problem behoben. Vielen Dank

Hinzufügen meiner Lösung für dieses Problem für alle, die möglicherweise helfen.

Ich hatte eine ClickOnce-Lösung, die diesen Fehler auslöste. Die App verwies auf einen gemeinsamen "Libs" -Ordner und enthielt eine Projektreferenz auf einen Foo.dll. Während keines der Projekte in der Lösung auf die statische Kopie von Foo.dll im Ordner "Libs" verwies, waren einige der Referenzen in diesem Ordner der Fall (dh: Meine Lösung hatte Verweise auf Libs\Bar.dll, auf die Foo.dll verwiesen wurde) Die Abhängigkeiten von Libs sowie ihre Abhängigkeiten, beide Kopien gingen in das Projekt ein. Dies erzeugte den obigen Fehler.

Ich habe das Problem behoben, indem ich meine Libs\Foo.dll-statische Version in einen Unterordner Libs\Fix\Foo.dll verschoben habe. Diese Änderung veranlasste die ClickOnce-App, nur die Projektversion von DLL zu verwenden, und der Fehler verschwand.

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

• Haben Sie mehrere Projekte in Ihrer Lösung
• Verfügen Sie über ein Projekt (Projekt A), das auf ein anderes Projekt (Projekt B) verweist, dessen Projekt auf ein NuGet-Paket verweist.
• In Projekt A haben Sie mit Intellisense/ReSharper den Verweis auf das in Projekt B referenzierte NuGet-Paket eingefügt (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.)
• aktualisierte das NuGet-Paket über NuGet Package Manager (oder CLI).

... Sie haben möglicherweise separate Versionen der NuGet-Pakete DLL in den Referenzen Ihres Projekts, da die von Intellisense/ReSharper erstellte Referenz eine "normale" Referenz und keine erwartete NuGet-Referenz ist, so NuGet Update-Prozess wird es nicht finden oder aktualisieren!

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 diese Antwort erklären )

Life Pro-Tipp:

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

sie müssen die Versammlung mit einem Schlüssel unterschreiben. Gehen Sie in den Projekteigenschaften unter der Registerkarte signieren:

Als mir dies nach dem Update mit dem WindowsAPICodePack passierte, habe ich die Lösung gerade neu aufgebaut.

Build -> Lösung neu erstellen

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

Es gab zu viele Projekte in meiner Lösung, um sie einzeln zu durchlaufen und einzeln zu aktualisieren.

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

Ist Ihre Versammlung ordnungsgemäß unterzeichnet?

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

Ich ging zu publish , Anwendungsdateien, fand die DLL, die den Fehler auslöste, in 'Include' aus 'Include (Auto)'. Ich kann jetzt veröffentlichen. 

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

Hier ist ein anderer Ansatz für 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>, der alle Ressourcen-Tags enthält.

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

• Ändern Sie das 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'.

Ich habe den ähnlichen Compiler-Fehler erhalten. Nachdem ich das abhängige Projekt der DLL-Datei zur Lösung hinzugefügt habe, wurde das Problem behoben. 

Dieses Problem ist nach der Migration eines Excel-Addins von packages.config nach PackageReference aufgetreten. Scheint verwandt mit diesem Problem zu sein .

Wenn Sie ClickOnce nicht verwenden, können Sie Folgendes umgehen: Wenn Sie ClickOnce nicht verwenden, werden alle Abhängigkeitsinformationen aus der Datei .manifest 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 .targets-Datei (in meinem Fall wurde die Datei in C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets aufgelöst und ich habe eine Kopie Microsoft.VisualStudio.Tools.Office_FIX.targets in demselben Ordner erstellt - nicht geprüft, ob sie aus einem anderen Ordner funktioniert).

4. Suchen Sie das GenerateApplicationManifest-Element und ändern Sie das Attribut Dependencies="@(DependenciesForGam)" in Dependencies="".

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

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

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

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

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

Was mir dabei geholfen hat, war, dass ich mit Package Manager Solution fortgefahren bin und das installierte Paket angesehen habe, das das Problem verursacht hat. Ich habe gesehen, dass mehrere Projekte auf dasselbe Paket, aber unterschiedliche Versionen verwiesen haben. Ich habe sie an meine Bedürfnisse angepasst und es hat funktioniert.

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

Versuchen Sie es mit Update-Paket -reinstall -ignoredependencies

Wenn die Abhängigkeiten von Abhängigkeiten nicht übereinstimmen, wechseln Sie zum NuGet-Paketmanager auf Lösungsebene, und überprüfen Sie die Registerkarten Aktualisieren und Konsolidieren. Vereinheitlichen Sie alle.

Ich stoße auch auf eine Art Problem, alles, was ich nur tun musste, ist die .dll löschen (kann in der Referenz gefunden werden), die den Fehler verursacht und es erneut hinzufügen . 

Klappt wunderbar. 

Ich habe dieses Problem vor kurzem getroffen. In meinem Fall habe ich NuGet-Pakete für verschiedene Baugruppen. Was ich hatte, waren verschiedene Versionen derselben NuGet-Pakete, die mit meinen eigenen Baugruppen verbunden 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 "Konsolidierungsoption", mit der Sie Ihre NuGet-Pakete für beliebig viele Projekte aktualisieren können, sodass alle auf dieselbe Version der Assembly verweisen. Wenn ich die Konsolidierungen durchführte, verschwand der Build-Fehler.

Ich hatte dies in einer Lösung mit 6 Projekten. Eines meiner Projekte bezog sich auf die genannte Assembly als Dateiverweis. Die anderen wiesen alle auf die Projektreferenz hin. 

In diesen Fällen erhalte ich normalerweise einen anderen Fehler. 

Meine Lösung bestand darin, die benannte Assembly überall dort zu löschen, wo sie referenziert wurde, und sie wieder hinzuzufügen. Nachdem ich das Projekt durchgearbeitet hatte, verschwand das Problem. Bevor ich dies tat, habe ich versucht, die Lösung zu reinigen und sicherzustellen, dass keines der Projekte unterschrieben wurde. 

hoffe es hilft jemandem ...