Może pcham kopertę tutaj, ale desperacko pragnę wykorzystać NuGet, aby złagodzić piekło DLL, w którym się znalazłem.

Mamy 4 główne produkty, które mieszkają w powiązanych repozytoriach Mercurial. Wszystkie z nich „współdzielą” 3 podstawowe zespoły, a wszystko inne jest ściśle związane z produktem. Teraz jest bardzo trudno zarządzać, ponieważ jeden produkt został uaktualniony do .NET 4.0 i korzysta z zewnętrznych zależności, które wymagają .NET 4.0, podczas gdy inny produkt utknął w .NET 3.5 z powodów, na które nawet nie chcę się dostać.

Straciliśmy więc zdolność łączenia różnic między produktami.

Aby to naprawić, chcę usunąć 3 główne zespoły i przekształcić je w swój własny projekt z własnym cyklem wydawniczym i zadbać o to, aby mogły się skompilować zarówno z .NET 3.5, jak i 4.0, a następnie przekształcić je w Pakiety NuGet zawierające wiele wersji szkieletowych.

ALE, chcę też, aby programiści mogli przeglądać źródło tych projektów.

Więc założyłemprywatny serwer NuGet i aprywatny serwer SymbolSource. Następnie ostrożnie połączyłem wszystkie zmiany ze wszystkich repozytoriów i wyrzuciłem wszystko poza moimi podstawowymi zestawami. Następnie starannie edytowałem ręcznie pliki .csproj tak, że zamiast platformy AnyCPU każdy projekt ma docelowe platformy 3.5 i 4.0, które określają stałe warunkowe (aby kontrolować funkcje specyficzne dla platformy, takie jak System.Dynamic) i ustawia wersję ramową.

Następnie ustawiam konfiguracje rozwiązań dla „3.5 Debug”, „3.5 Release”, „4.0 Debug” i „4.0 Release”. Każdy z nich kieruje się do odpowiedniej konfiguracji (debugowania lub zwalniania) i platformy (3.5 lub 4.0).

Mogę zbudować wszystko dobrze w Visual Studio dla dowolnej platformy. Teraz mam problem, jeśli chodzi o NuGet, ponieważ istnieją dwa sposoby tworzenia pakietu i oba mają słabość, chyba że czegoś mi brakuje:

Pakiet według pliku projektu

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

Problemy z tym to:

Podczas gdy wersja 3.5 jest zbudowana i spakowana, dane wyjściowe mówią: „Budowanie projekcji dla frameworka docelowego .NETFramework, Version = v4.0”. ”Jeśli rozpakuję otrzymane pakiety, zespoły są podlib\net40 co jest złe.Nie sądzę, aby w ten sposób można było spakować 2 cele frameworkowe, trzeba to zrobić w inny sposób, z folderami i konwencjami.Jestem gotów zaakceptować, że nie możesz spakować frameworków razem i utworzyć 2 pakiety o nazwie MyProject (co zrobiłbym jako 4.0) i MyProject.V35 ... jednak nie mogę wymyślić, jak mieć ten sam projekt i nuspec i zakończ z 2 różnymi wynikami o różnych identyfikatorach.

Pakiet Nuspec File

Dzięki tej metodzie muszę samodzielnie wykonać całą operację msbuilding, a następnie wykonać kilka operacji kopiowania plików, aby skonfigurować strukturę folderów

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

Potem mogę biecnuget pack MyProject.nuspec ale nie ma źródła, które zawierałoby symbole, ponieważ bez pliku .csproj NuGet nie ma sposobu, aby dowiedzieć się, skąd wziąć wszystkie pliki źródłowe i nie widzę żadnej dokumentacji dotyczącej tego, jak to zrobić za pomocą konwencji katalogów zarówno.

Moje pytania to:

Czy istnieje sposób dodawania plików źródłowych do pakietu opartego na konwencji?Czy istnieje sposób na dwukrotne spakowanie pakietu opartego na projekcie z różnymi identyfikatorami?Czy jest inna aleja, której być może nie rozważałem?

Wszelkie myśli byłyby bardzo mile widziane.