2016-10-04 3 views
2

Ich habe 2 Projekte in meiner Lösung. Die erste ist eine portable Bibliothek, die auf .NET Standard 1.3 abzielt. Diese Bibliothek ist von Json.NET abhängig. Seine project.json sieht wie folgt aus:Abhängigkeiten funktionieren nicht, wenn .NET Standard 1.3-Bibliothek von .NET 4.6.1 app referenziert

{ 
    "supports": {}, 
    "dependencies": { 
    "Microsoft.NETCore.Portable.Compatibility": "1.0.1", 
    "NETStandard.Library": "1.6.0", 
    "Newtonsoft.Json": "9.0.1" 
    }, 
    "frameworks": { 
    "netstandard1.3": {} 
    } 
} 

Bibliothek besteht aus nur dieser einfachen Klasse:

using Newtonsoft.Json; 
using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Text; 

namespace TestLibrary 
{ 
    public class TestClass 
    { 
     public static string Foo() { 
      return JsonConvert.SerializeObject(42); 
     } 
    } 
} 

Zweites Projekt Konsolenanwendung ist voll .NET 4.6.1 Rahmen Targeting. Diese Konsolenanwendung verweist auf die oben erwähnte Bibliothek. Code folgt:

namespace ConsoleApplication 
{ 
    class Program 
    { 
     static void Main(string[] args) 
     { 
      var x = TestLibrary.TestClass.Foo(); 
     } 
    } 
} 

Ich bin in der Lage, es zu bauen und laufen, aber TestLibrary.TestClass.Foo() Ergebnisse in folgenden Ausnahme Aufruf:

kann nicht Datei oder Assembly ‚Newtonsoft.Json, Version = 9.0 laden. 0.0, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed 'oder eine seiner Abhängigkeiten. Das System die angegebene Datei nicht finden kann. ":" Newtonsoft.Json, Version = 9.0.0.0, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed“

Es gibt keine Newtonsoft.Json.dll in meinem Binärordner

ich habe. Visual Studio 2015 Update 3 (KB3165756) installiert (14.0.25431.01, veröffentlicht am 14.09.2016) sowie .NET Core 1.0.1 VS 2015 Tooling Preview 2.

Nach zu viel Zeit Googeln, ich ' Ich bin mir nicht sicher ob a) Ich mache etwas falsch b) Tooling unterstützt dieses Szenario noch nicht c) Meine Visual Studio Installation ist irgendwie kaputt.

EDIT: Hier ist complete solution to reproduce.

+0

Sind beide ClassLibrary und Console App .NET Core-Anwendung? Ich erschaffe beides.NET Core ClassLibrary und Console App basierend auf Ihrer Beschreibung, ich bekomme keine Fehlermeldung. Wenn möglich, schlage ich vor, dass Sie ein Beispielprojekt bereitstellen. Ich werde Ihre App auf meiner Seite ausführen, um zu bestätigen, ob bei der Projekt- oder VS-Installation ein Problem vorliegt. –

+0

Nein, sie sind nicht .NET Core. Die Bibliothek ist PCL-Targeting für .NET Standard 1.3 und die Konsolen-App zielt auf das vollständige .NET 4.6.1-Framework ab. Sie finden Beispielprojekt [hier] (http://www.esentio.sk/temp/testdependencies.zip) (GitHub kann momentan nicht verwendet werden). – Stalker

Antwort

2

Das PCL-Bibliotheksprojekt verwaltet Pakete mit der Datei project.json, aber die gängigen .NET Framework-Projekte verwalten NuGet-Pakete mit packages.config.

Ich habe getestet, wenn ich das Newtonsoft.Json-Paket manuell in Ihrer Konsole-Anwendung installiere, könnte es erfolgreich ausgeführt werden. Und wenn ich das PCL-Bibliotheksprojekt mit der .NET Core Console-App referenziere, die auch NuGet-Pakete mit der Datei project.json verwaltet, könnte die Lösung ebenfalls erfolgreich ausgeführt werden.

In Ihrer Situation müssen Sie die NuGet-Pakete installieren, die in der PCL-Bibliothek manuell in Ihre Konsolenanwendung projiziert werden.

+1

Ja, wenn ich die Abhängigkeiten zur Konsolen-App installiere, funktioniert es. Und ja, ich vermutete, dass es etwas mit project.json/packages.config differencies zu tun hat. Aber die Hauptfrage bleibt: Wird dieses Szenario nicht von Werkzeugen unterstützt? Wird es in Zukunft behoben werden? Ich kann keine Antwort darauf finden (vielleicht bin ich nur schlecht darin, es zu googeln). Weil mein Szenario der realen Welt viel komplexer ist und es lästig ist, wenn ich Abhängigkeiten in allen Projekten kopieren muss, die auf Standardbibliotheksprojekt verweisen. Wie auch immer, ich werde deine Antwort akzeptieren, da sie das Problem löst. – Stalker

+0

Ich finde auch keine Nachrichten darüber, ob dieses Szenario nicht unterstützt wird oder nicht. Laut dem Dokument von NuGet heißt es: "Weitere Informationen finden Sie in den FAQ zum Verhaltenskodex oder kontaktieren Sie [email protected] mit weiteren Fragen oder Kommentaren". Daher schlage ich vor, dass Sie sich an [email protected] wenden, um dieses Problem zu übermitteln. –

+0

Die akzeptierte Antwort ist veraltet, da project.json nicht mehr für den .net-Standard verwendet wird. Sie verwenden jetzt eine .csproj. – trampster

2

Sie müssen die .NET Standard-Bibliotheken nicht manuell installieren.

Microsoft schließlich räumte ein, dass dies ein Problem ist und will fix es erwartungsgemäß in NuGet Version 4.0.1, das erste Update auf NuGet 4 nach VS 2017 Schiffe.

Die sauberste Problemumgehung besteht nun darin, <RestoreProjectStyle>PackageReference</RestoreProjectStyle> zu einem Legacy-Projekt (.NET 4.6.1. App in diesem Fall) hinzuzufügen. Jedoch according to Rob Relyea MS wird diese Eigenschaft nach RTM ignorieren, so eine andere Problemumgehung ist <PackageReference Update="PlaceholderToConvinceThisProjectToGetTransitivePackageReferenceFromProjectReferences"/>.

Eine andere Problemumgehung ist das Packen einer .NET-Standardbibliothek in NuGet-Paket wie in that answer, aber es ist nicht der einfachste Weg.

Verwandte Themen