web-dev-qa-db-ger.com

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

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

254
Sergey Kucher

Ich vermute, dass Sie nicht mit stark benannten Baugruppen arbeiten. Ich habe diesen Fehler gehabt, wenn zwei Projekte auf etwas 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 ohnehin egal) und dann einen sauberen Build durchzuführen.

Änderungen zwischen den verschiedenen Assembly-Versionen 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 durchführen, um das Problem zu beheben.

NuGet

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

  1. Sie installieren ein Paket für ein Projekt in Ihrer Projektmappe.
  2. Eine neue Version dieses Pakets wird in der 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 das Problem zu beheben, geben Sie den Befehl update-package [package name] in der Nuget Package Manager Console ein, um alles auf ein gleiches Spielfeld zu bringen, woraufhin das Problem behoben ist.

Sie sollten NuGet-Pakete auf Lösungsebene und nicht auf Projektebene verwalten, sofern nicht zwingende Gründe vorliegen. Das Paketmanagement auf Lösungsebene vermeidet das Potenzial mehrerer Versionen von Abhängigkeiten. Wenn bei Verwendung der Verwaltungsbenutzeroberfläche auf der Registerkarte Consolidated angezeigt wird, dass ein oder mehrere Pakete über mehrere Versionen verfügen, sollten Sie sie auf eine konsolidieren.

231
CRAGIN

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

260
CharleZ

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.

65
Otiel

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

23
Krishh

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.

21
daniel

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.

13
Sogger

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

6
Kishore

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.

6
Nick Gotch

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.

6
David Murdoch

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

6
Felice Pollano

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

Build -> Lösung neu erstellen

5
Nathan

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

4
ChrisO

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

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 .

3

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

3
Jimmy

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.

3
Hoang Ha

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'.
3
Tech

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. 

2
Minny

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

2
FunctorSalad

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.

2
Huy Nguyen

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.

1
Artexias

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.

0
PatFromCanada

Versuchen Sie es mit Update-Paket -reinstall -ignoredependencies

0
Stella Oliveira

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.

0
Luke Puplett

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. 

0
FritsJ

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.

0
Simon Miller

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

0
greg