.NET 4.6 Projekt Referenzierung .NET standrad lib Projekt, das Pakete installiert

Question

Es gibt zwei Projekte NuGet hat:

a.csproj -> .NET 4.6.1 
b.csproj -> .NET Standard 1.3 

Es gibt eine Klasse in jedem der Projekte:

a.csproj has class A (.NET 4.6.1) 
b.csproj has class B (.NET Standard 1.3) 

Fall 1 : Eine ruft eine Methode von B, wo die Methode etwas zurückgibt, sagen wir String. Alles funktioniert gut.

Fall 2: A ruft eine Methode aus B wobei das Verfahren druckt sagen zu einer Konsole kann. in A erhalten Sie eine Ausnahme "Datei oder Assembly System.Console konnte nicht geladen werden". Um dies zu beheben, fügen Sie einen Verweis auf "NETStandard.Library" in a.csproj Projekt hinzu. Danach funktioniert alles gut.

Fall 3: A ruft eine Methode aus B wobei das Verfahren einiger DLL verwendet MySQLdata oder HtmlAgility Pack oder w/e von einem NuGet Paket installiert sagen lassen. In A erhalten Sie eine Ausnahme "Datei oder Assembly konnte nicht geladen werden". Um dies zu beheben, installieren Sie das gleiche Paket in a.csproj Projekt, aber je nach Paket können Sie innere Ausnahme "Starke Namensvalidierung fehlgeschlagen" innere Ausnahme erhalten.

Wie behandelt man den Fall 3?

Answer 1

Sie müssten die innere Ausnahme sorgfältig analysieren, um zu sehen, welche Baugruppe sie auslöst.

.NET Core Tooling-basierte Projekte wie .NET Standard Class Library-Projekte führen das Konzept des "öffentlichen Signierens" ein (ähnlich dem verzögerten Signieren). Also, wenn ein Projekt ist so konfiguriert, wie

<PublicSign>True</PublicSign> 

Dann wird die kompilierte Assembly kann nur von .NET-Core-Anwendungen verbraucht werden, da sie öffentlich unterzeichnet Baugruppen akzeptieren.

sollte Ein richtiges Projekt

<PublicSign Condition=" '$(OS)' != 'Windows_NT' ">True</PublicSign> 

verwenden, so dass seine Ausgabe von .NET Framework-Projekte werden verbraucht wird.

Suchen Sie die Täter-Baugruppe, die nicht ordnungsgemäß signiert wurde, und melden Sie sich bei den Entwicklern. Sobald das Problem mit der Signatur behoben und eine neue Version des NuGet-Pakets bereitgestellt wurde, kann das Problem behoben werden.

Wenn Sie nur um es umgehen möchten, können Sie wahrscheinlich Unterzeichnung Praxis verzögern folgen Validierung starken Namen auf Ihrer Maschinen vorübergehend zu unterdrücken,

https://docs.microsoft.com/en-us/dotnet/framework/app-domains/delay-sign-assembly