Workflow zum Referenzieren von Projekten in mehreren VS 2017-Lösungen

Question

Ich suche nach Informationen über Best Practices beim Referenzieren von C# -Projekten in mehreren Lösungen, sowohl im Debug- als auch im Release-Modus. nugget und symbol server (ich benutze myget, und mag es wirklich) löst das für release packages.

Aber ich bin verwirrt darüber, was beim Debuggen zu tun ist. Wenn ich versuche, beim nuget-Ansatz zu bleiben, muss ich eine neue Debug-Version von Hilfspaketen an myget finden, da ich & Fehler finden kann, und dann den Nuget-Cache löschen und das Hauptprojekt neu erstellen. Das funktioniert, aber es wird schnell langweilig.

Gibt es eine Möglichkeit, ein Nuget-Paket zu markieren, so dass es als "nur für Debug-Verwendung" markiert ist?

war eine andere Idee hatte ich die Fähigkeiten des neuen csproj Dateiformat in VS 2017 wie folgt zu verwenden:

<ItemGroup Condition="'$(Configuration)' == 'Release'"> 
    <PackageReference Include="Olbert.JumpForJoy.UI" Version="0.5.0" /> 
    <PackageReference Include="Olbert.JumpForJoy.Wpf.Converters" Version="0.5.0" /> 
    </ItemGroup> 

    <ItemGroup Condition="'$(Configuration)' == 'Debug'"> 
    <ProjectReference Include="..\..\WPFUtilities\J4JUI\J4JUI.csproj" /> 
    <ProjectReference Include="..\..\WPFUtilities\WpfConverters\WpfConverters.csproj" /> 
    </ItemGroup> 

Der erste Block die nuget Pakete verwendet, aber nur für Release-Builds. Der zweite Punkt verweist auf das Hauptprojekt bei den Tochterprojekten in meinem lokalen Dateisystem. Dies scheint mir die Möglichkeit zu geben, die Teilprojekte aus dem Hauptprojekt herauszuarbeiten. Aber um das Hauptprojekt aufzubauen, muss ich alle Nebenprojekte in die Lösung einbeziehen. Das ist keine große Sache, aber es füllt den Lösungsarbeitsbereich auf.

Wenn jemand andere Ansätze, die sie verwenden, oder Feedback zu dem, was ich tue (besonders Gotchas!), Ich bin ganz Ohr.

Answer 1

Da alle meine Projekte innerhalb des Dateisystem meines Entwicklungssystems verfügbar sind, erkannte ich, dass es für mich unnötig war, Pakete für Debug-Versionen zu veröffentlichen. Grundsätzlich sollte ich nur den Quellcode lokal ändern und nur Release-Pakete veröffentlichen.

konnte ich die „Unordnung“ Problem lösen in einer VS-Lösung verwiesen viele Tochtergesellschaft Projekte mit durch eine einzige Lösung Ordner zu erstellen, und das Hinzufügen alle notwendigen Tochtergesellschaft Projekte zu.

Zugegeben, dies kann das Leben von irgendjemandem erschweren, der versucht, meine Open-Source-Software zu verwenden - sie müssten alle Nebenpakete klonen, egal für welches primäres Programm sie sich interessieren - aber das ist sicherlich machbar .