2016-04-24 5 views
5

Es ist üblich, eine große Lösung ist mehrere Projekte für eine Frage der Organisation der Codebasis zu brechen, und dies war einfach in den früheren Versionen von .NET Framework von innerhalb von Visual Studio.Wie spezifiziert man Abhängigkeiten von anderen Projekten mit .NET CLI?

Wie das gleiche mit .NET CLI getan werden kann? Angenommen, wir das folgende vereinfachte Szenario zum Beispiel haben:

- Solution Folder 
    - global.json 
    - src 
     - LibProject 
     - ConsoleProject 

Nehmen wir nun an, dass die ConsoleProject auf dem LibProject abhängt. Intuitiv glaube ich, dass dies bedeutet, dass in der ConsoleProject die project.json einen dependencies Abschnitt wie diese enthalten müssen:

"dependencies": { 
    "Microsoft.NETCore.App": { 
     "type": "platform", 
     "version": "1.0.0-*" 
    }, 
    "LibProject": "1.0.0-*" 
} 

Aber wenn wir das tun, wenn wir versuchen, die Abhängigkeiten wiederherzustellen für die ConsoleProject oder wenn wir versuchen, bau es, wir können es nicht tun. Wenn wir versuchen, wiederherzustellen, erhalten wir die Nachricht

Konnte 'LibProject (> = 1.0.0)' für '.NETCoreApp, Version = v1.0' nicht auflösen.

Ich verstehe den Grund. Beim Wiederherstellen versucht NuGet, dies als Paket für die angegebenen Feeds unter NuGet.config zu finden. Aber es sollte nicht so sein, es sollte das auf dem Geschwister-Ordner verwenden.

In den vorherigen Versionen von .NET Core, würden wir die Referenz über VS hinzufügen und dann, wenn wir versuchen würden, die ConsoleProject zu bauen, würde VS zunächst LibProject erstellen und die entsprechende DLL verwenden.

Wie die gleiche Sache hier gemacht wird? Wie können wir ein anderes Projekt in derselben Lösung referenzieren und wie können wir die .NET CLI unter Berücksichtigung dieser Art von Abhängigkeit wiederherstellen/erstellen/ausführen?

+1

Glück gehabt, wenn Sie tun ' "libproject": { "Ziel": "Projekt"} '? – khellang

+0

In neueren Versionen des Dotnet-Clients, die das 'csproj'-Format verwenden, können Sie' dotnet add reference ../ MyProject/MyProject.csproj' https://docs.microsoft.com/en-us/dotnet/core ausführen/tools/dotnet-add-reference – dbattaglia

Antwort

4

Nachdem Sie die Projekte definiert haben, die die Lösung für die Datei global.json hat, können Sie sie einfach auf der project.json mit Namen ohne eine bestimmte Version referenzieren.

Beispiel:

global.json

{ 
    "projects":[ 
     "ConsoleProject", 
     "LibProject" 
    ] 
} 

ConsoleProject/project.json

{ 
    "dependencies":{ 
     "LibProject":"", 
    } 
} 

Sie können hier ein besseres Beispiel finden: http://forums.dotnetfoundation.org/t/referencing-another-project-in-net-core/1298/2

Oder in diesem Repository : https://github.com/cartermp/dnx-apps/tree/master/multiple-projects

+0

Danke für die Antwort, aber das hat nicht funktioniert. Vielleicht hat es vorher mit DNX funktioniert, aber mit .NET CLI funktioniert es nicht. In Wahrheit erscheint dieser Ansatz seltsam, weil wir 'dotnet restore' aus dem Ordner' src/ConsoleProject' ausführen, während 'global.json' auf der Seite des' src'-Ordners sitzt, so dass 'dotnet' toolchain nicht sehen kann es. Wie auch immer, das Problem, mit dem ich konfrontiert bin, ist nicht das Spezifizieren einer Version, sondern das '' dotnet restore'' wählt 'LibProject' aus dem Geschwister-Ordner, anstatt auf die NuGet-Feeds zu schauen. – user1620696

+0

Es sieht so aus, dass die Datei global.json nicht mehr benötigt wird. Welche Version von dot net cli verwenden Sie? Hier ist ein ähnliches Problem wie bei Ihnen und scheint zu funktionieren. https://github.com/dotnet/cli/issues/966#issuecomment-174206475 –

+1

Es ist die Version 1.0.0-rc2-002476. Wie auch immer, ich habe es jetzt geschafft, es war ein Tippfehler auf die Abhängigkeiten, die das Problem verursacht haben. Wie auch immer: Es gibt einige Details, die ich herausgefunden habe - für die Verwendung der 'dotnet' Toolchain wird die 'global.json'-Datei nicht wirklich benötigt, aber sie wird für Omnisharp-Arbeit direkt in VS Code benötigt. Außerdem können wir tatsächlich auf die Version des Projekts verweisen, wie '" LibProject ":" 1.0.0 - * "' das funktioniert auch gut. Danke für die Hilfe. – user1620696

2

Nach the documentation on writing libraries, die neue korrekte Art und Weise an einem anderen Projekt eine Abhängigkeit Angabe in der Lösung:

{ 
    "dependencies":{ 
     "AwesomeLibrary.Core": { 
      "version": "1.0.0", 
      "target": "project" 
     } 
    } 
} 

Die target: project Bit NuGet sagt, dass es nicht in einer Paketquelle aussehen sollte.

Dies vorausgesetzt, dass Sie die folgende Verzeichnisstruktur für Ihre Lösung haben:

AwesomeLibrary 
|__global.json 
|__/src 
    |__/AwesomeLibrary.Core 
     |__Source Files 
     |__project.json 
    |__/AwesomeLibrary.Other 
     |__Source Files 
     |__project.json 
/test 
    (... etc) 

Mit einer global.json Datei wie:

{ 
    "projects":["src", "test"] 
} 
+1

Der Dokumentationslink ist jetzt unterbrochen. Ich konnte diese Arbeit nicht machen. Ich nehme an, dass sie die Werkzeuge wieder gewechselt haben, da die Hilfe nicht mehr da ist. – trevorc

+1

Aktualisierter Link: https://docs.microsoft.com/en-us/dotnet/articles/core/tutorials/libraries#how-to-use-multiple-projects –

+0

Aktualisiert. Danke @tanguy_k! –