Ich experimentiere mit Visual Studio 2015 RC, insbesondere mit Blick auf den Wechsel zu den neuen ASP.NET 5-Framework, Projektstruktur und die neue DNX, die ASP.NET 5-Anwendungen ausgeführt wird.Welche Möglichkeiten gibt es, Code zwischen DNX/ASP.NET 5-Projekten (project.json/xproj) und anderen C# -Projekten (csproj) in einer einzigen Lösung zu teilen?

Mein Arbeitgeber hat viele bestehende Lösungen für .NET Framework 4.5.2. In unseren bestehenden Visual Studio-Lösungen könnten wir folgende Projekte:

[Solution] Sample.sln 
    [Folder] src 
     [Project] ClassLibrary.csproj 
     [Project] WindowsService.csproj 
     [Project] WebApplication.csproj 
    [Folder] test 
     [Project] ClassLibrary.UnitTests.csproj 
     ...

In diesem Szenario ist ClassLibrary.csproj eine C# Klassenbibliothek gemeinsamen Code enthält. Es ist eine Abhängigkeit von sowohl WindowsService.csproj als auch WebApplication.csproj.

Wir versuchen nicht speziell auf .NET Core dnxcore50 zu zielen. In diesem Stadium freuen wir uns auf .NET Framework, dnx451. Wir versuchen jedoch unbedingt, die neuen Funktionen von ASP.NET 5 und die zugehörige Projektstruktur zu nutzen.

Unten sind einige Optionen, an die ich gedacht habe, aber beide haben Probleme.

Option 1

Wenn wir ersetzen die WebApplication.csproj Projekt oben mit einem neuen ASP.NET 5 DNX Projekt WebApplication-dnx dann können wir von den ClassLibrary.csproj beide dieses neue Projekt DNX Referenz noch und das bestehende WindowsService.csproj Projekt. Allerdings ergeben sich einige Fragen:

Dieser Ansatz bedeutet, alle Änderungen an Code in ClassLibrary.csproj müssen ein sichtbares im laufenden WebApplication-dnx werden wieder aufzubauen. Dies ist nicht verwunderlich, bedeutet aber, dass wir keine vollständigen Kompilierung-aus-Quellen-Vorteile für WebApplication-dnx erhalten.
Wir können andere Frameworks, z. dnxcore50. Wie oben, ist dies in diesem Stadium kein spezifisches Ziel.

Option 2

Wenn wir ClassLibrary.csproj mit DNX Klassenbibliotheksprojekt ersetzen^ClassLibrary-dnx dann 1 die Probleme in Option nicht gelten. Dieser Ansatz scheint eher mit der Art und Weise übereinzustimmen, in der die .NET-Laufzeitumgebung und die damit verbundenen Technologien wie ASP.NET nach vorne verpackt werden.

Allerdings kann ich keinen Weg finden, ClassLibrary-dnx von WindowsService.csproj zu referenzieren. Wenn dieser Ansatz realisierbar ist, stelle ich mir vor, dass die Lösung etwas mit der Option Produce outputs on build für die Projektebene zu tun hat und dann auf die .nupkg oder vielleicht sogar auf die .dll verweist, die während des Builds erzeugt wird. Ich sehe jedoch keinen sauberen Weg, dies über das Werkzeug zu erreichen.

^DNX Klassenbibliothek Projekte heißen Class Library (Package) in VS 2015 RC. Dieser Projekttyp wurde zuvor in den CTPs ASP.NET Class Library genannt.

Zusammenfassung

Basierend auf den Informationen über ich suche:

Einige Feedback zu meinem Szenario Optionen und Fragen.
Vorschläge für andere Optionen, an die ich nicht gedacht habe.
Vielleicht ein Hinweis darauf, welcher Ansatz verwendet werden sollte.

Quelle

2015-05-20 Matt Brooks

Haben Sie überlegt, ob 'dnu wrap' funktioniert? Das Wrapping von .csproj-Dateien in project.json-Dateien. – vcsjones

Ja, mein Verständnis ist das, was das Tooling jetzt für Sie tut, wenn Sie einen Verweis auf das .csproj wie in Option 1 oben hinzufügen. –

Ich habe es nicht ausprobiert, kann also kein vollständiges Write-up machen, aber für Option 2 könntest du vielleicht "Outputs auf Build" deines xproj produzieren und dann einen lokalen NuGet-Feed hinzufügen, der auf dein Artefaktverzeichnis zeigt das NuGet-Paket. Vielleicht werde ich später noch eine Chance bekommen. –

Werfen Sie einen Blick auf das, was EntityFramework tut.

Sie zielen auf 3 TFMS: net45, .NETPortable, Version = v4.5, Profile = Profile7, frameworkAssemblies und sie haben beide csproj und xproj in the same folder.

Grundsätzlich haben Sie für jedes Projekt zwei Projektdateien.

Allerdings kann ich keine Möglichkeit finden, ClassLibrary-dnx von WindowsService.csproj verweisen.

Leider ist das noch nicht möglich. Sie können csproj nur von xproj aus referenzieren, nicht umgekehrt. Sie haben zwei Alternativen: (1) haben Sie sowohl xproj und csproj wie EF oder (2) referenzieren das NuGet-Paket von csproj.

Wenn Sie eine Alternative (2) erstellen möchten, können Sie die Ausgabe von xproj auf einen Ordner setzen und diesen als NuGet-Feed hinzufügen.

Quelle

2015-05-21 15:56:07

Vielen Dank für die Referenzen. Ich werde mit dem Ansatz für (1) experimentieren. Sie erwähnen "nicht möglich, noch nicht". Stehe ich Ihrer Meinung nach vor diesem Problem, weil die Werkzeuge die Unterstützung für Ihre vorgeschlagenen Arbeitsabläufe (1) oder (2) oder beide derzeit nicht unterstützen? Siehe mein [Kommentar] (http://stackoverflow.com/questions/30355208/what-are-my-options-for-sharing-code-between-asp-net-5-projects-xproj-and-oth#comment48839618_30355208) oben für Probleme, die ich mit Workflow (2) betrachte. –

Es gibt keine Unterstützung für Ihr Szenario in Tooling, aber Sie können es mit allem erreichen, was heute öffentlich existiert: Fügen Sie einen Ordner als NuGet-Feed hinzu und erstellen Sie einen Pre-Build-Schritt im csproj, der NuGet zur Aktualisierung des Pakets aufruft. Ein anderer, einfacherer Weg ist, nur auf die von xproj erzeugte Binärdatei zu verweisen, statt auf die nupkg –

. Ich habe diesen Punkt von @VictorHurdugaci vergessen - die rohen DLLs werden nach '{solutionFolder} \ artifacts \ bin \ {xprojName} \ {configuration} \ { Plattform} '; Sie könnten auf diese Weise auf sie verweisen, anstatt einen Ordner als NuGet-Feed zu verwenden. –

Welche Möglichkeiten gibt es, Code zwischen DNX/ASP.NET 5-Projekten (project.json/xproj) und anderen C# -Projekten (csproj) in einer einzigen Lösung zu teilen?

Option 1

Option 2

Zusammenfassung

Antwort

Verwandte Themen