Vielleicht schiebe ich den Umschlag hierher, aber ich bin verzweifelt daran, NuGet zu nutzen, um die DLL-Hölle zu lindern, in der ich mich befunden habe.

Wir haben 4 Hauptprodukte, die alle in zusammenhängenden Mercurial-Repositories leben. Alle "teilen" sich 3 Kernbaugruppen und dann ist alles andere so ziemlich produktspezifisch. Die Verwaltung ist jetzt sehr schwierig, da ein Produkt auf .NET 4.0 aktualisiert wurde und externe Abhängigkeiten verwendet, für die .NET 4.0 erforderlich ist, während ein anderes Produkt aus Gründen, auf die ich nicht einmal eingehen möchte, in .NET 3.5 steckt.

Daher haben wir unsere Fähigkeit verloren, Unterschiede zwischen Produkten zusammenzuführen.

Um das Problem zu beheben, möchte ich die drei Hauptassemblys herausnehmen und sie in ein eigenes Projekt mit einem eigenen Release-Zyklus umwandeln und sicherstellen, dass sie sowohl mit .NET 3.5 als auch mit .NET 4.0 kompatibel sind, und diese dann in NuGet-Pakete mit mehreren Framework-Versionen.

ABER ich möchte auch, dass Entwickler die Quelle dieser Projekte durchsuchen können.

Also habe ich eineprivater NuGet Server und einPrivater SymbolSource-Server. Dann habe ich alle Änderungen aus allen Repositorys sorgfältig zusammengeführt und alles außer meinen Kern-Assemblys verworfen. Dann habe ich die .csproj-Dateien sorgfältig von Hand bearbeitet, sodass jedes Projekt anstelle der AnyCPU-Plattform Plattformziele von 3.5 und 4.0 aufweist, die bedingte Konstanten (zur Steuerung plattformspezifischer Funktionen wie System.Dynamic) angeben und die Framework-Version festlegen.

Dann richte ich Lösungskonfigurationen für "3.5 Debug", "3.5 Release", "4.0 Debug" und "4.0 Release" ein. Jedes zielt auf die entsprechende Konfiguration (Debug oder Release) und Plattform (3.5 oder 4.0) ab.

Ich kann alles gut in Visual Studio für jede Plattform erstellen. Jetzt habe ich ein Problem mit NuGet, da es zwei Möglichkeiten gibt, ein Paket zu erstellen, und beide haben eine Schwäche, es sei denn, mir fehlt etwas:

Paket nach Projektdatei

nuget pack MyProject.csproj -Build -Symbols -Version <insert-from-build-server> -Properties "Configuration=Release;Platform=3.5;"

Die Probleme dabei sind:

Während die 3.5-Version erstellt und gepackt wird, wird in der Ausgabe "Building projecct for target framework '.NETFramework, Version = v4.0'" angezeigt.Wenn ich die resultierenden Pakete auspacke, befinden sich die Baugruppen unterlib\net40 was falsch ist.Ich glaube nicht, dass es eine Möglichkeit gibt, 2 Framework-Ziele auf diese Weise zu packen. Sie müssen dies mit Ordnern und Konventionen anders machen.Ich bin bereit zu akzeptieren, dass Sie die Frameworks nicht zusammen packen können und 2 Pakete mit dem Namen MyProject (was ich als 4.0 machen würde) und MyProject.V35 machen können ... aber ich kann nicht herausfinden, wie man das gleiche Projekt und Nuspec hat und ende mit 2 verschiedenen ergebnissen mit verschiedenen ids.

Paket von Nuspec-Datei

Mit dieser Methode muss ich alles selbst bauen und dann ein paar Dateien kopieren, um eine Ordnerstruktur wie diese einzurichten

* MyProject.nuspec
* net40
    * MyProject.dll
    * MyProject.pdb
* net35
    * MyProject.dll
    * MyProject.pdb

Dann kann ich rennennuget pack MyProject.nuspec Aber dann gibt es keine Quelle für die Symbole, da NuGet ohne die .csproj-Datei keine Möglichkeit hat, herauszufinden, woher alle Quelldateien stammen, und ich sehe keine Dokumentation, wie dies mit Hilfe von Verzeichniskonventionen geschehen soll entweder.

Meine Fragen sind also:

Gibt es eine Möglichkeit, Quelldateien zu einem konventionellen Paket hinzuzufügen?Gibt es eine Möglichkeit, ein projektbasiertes Paket zweimal mit unterschiedlichen IDs zu packen?Gibt es eine andere Straße, die ich vielleicht nicht in Betracht gezogen habe?

Alle mögliche Gedanken würden sehr geschätzt.