Najlepsze praktyki z Nuget: Debugowanie lub wydawanie?

Question

Obecnie kompiluję wersje wydań z Nuget dla oficjalnych kompilacji na nuget.org, ale pakuję kompilacje debugowania z Nuget, aby źródło symbolu przepchało się do symbolsource.org.

EDIT: (Jon Skeet, z jakiegoś błędu z rozwojem Noda czas)

Nuget teraz obsługuje zarówno do pchania galerii Nuget i symbolsource.org (lub podobny), serwery as documented. Niestety, istnieją dwa przeciwstawne wymagania tutaj:

• Kiedy tylko użyciu bibliotekę bez potrzeby debugowania, naprawdę chcesz kompilacji uwolnienia. W końcu to są kompilacje wydań.
• Podczas debugowania biblioteki do celów diagnostycznych, naprawdę potrzebujesz kompilacji debugowania z wyłączonymi wszystkimi odpowiednimi optymalizacjami. W końcu to są właśnie wersje do debugowania.

To byłoby w porządku, ale NuGet (o ile wiem) nie pozwala, aby kompilacje wydania i debugowania były publikowane w użyteczny sposób, w tym samym pakiecie.

Tak, do wyboru są:

• rozprowadzić debug buduje dla każdego (jak pokazano w przykładzie z docs) i żyć z dowolnej wielkości i wydajności trafień.
• Rozłóż kompilacje wydań wszystkim i żyj z lekko ograniczonym doświadczeniem debugowania.
• Przejdź do bardzo skomplikowanej polityki dystrybucji, potencjalnie dostarczając osobne pakiety wydań i debugowania.

Pierwsze dwa naprawdę sprowadzają się do wpływu różnic między debugowania i uwalniania buduje ... choć warto zauważyć, że istnieje również duża różnica między chcąc wkraczać do kodu biblioteki, ponieważ chcesz sprawdź zachowanie i chcesz debugować kod biblioteki, ponieważ uważasz, że znalazłeś błąd. W drugim przypadku lepiej jest uzyskać kod biblioteki jako rozwiązanie Visual Studio i debugować w ten sposób, więc nie zwracam zbyt dużej uwagi na tę sytuację.

My pokusa jest po prostu trzymać się z wydaniem buduje, z oczekiwaniem, że stosunkowo niewiele osób będzie potrzebować do debugowania, a tymi, którzy robią nie będzie miała wpływu znacznie przez optymalizacje w budowie uwalnianiu. (Kompilator JIT wykonuje większość optymalizacji.)

Czy są inne opcje, których nie rozważaliśmy? Czy istnieją inne czynniki, które przechylają równowagę? Czy pchanie pakietów NuGet do SymbolSource jest wystarczająco nowe, że "najlepsza praktyka" naprawdę nie została ustalona?

Answer 1

Mówiąc o SymbolSource uważam, że najlepszym rozwiązaniem jest:

1. push + pakiety binarne uwolnienia do treści tylko nuget.org (lub jakakolwiek inna produkcja pasz) Pakiety
2. push debug binarne + content paszy rozwój:
   • w siedzibie
   • na myget.org
   • na nuget.org jako pakiety przedpremierowych.
3. Przesyłaj oba pakiety symboli binarnych i debugowania do symboluource.org lub dowolnego innego magazynu symboli.

Podczas gdy jesteśmy na tym, to jest powszechne nieporozumienie, że budowanie wersji i debugowania w .NET naprawdę różni się znacznie, ale zakładam, że zróżnicowanie jest tutaj z powodu różnych kodów, które mogą lub nie mogą być zawarte w obu kompilacjach, takich jak Debug.Asserts.

To powiedziawszy, naprawdę warto przepchnąć obie konfiguracje do SymbolSource, ponieważ nigdy nie wiadomo, kiedy będzie trzeba debugować kod produkcyjny. Zdalnie w produkcji, aby było trudniej. Będziesz potrzebować pomocy, którą możesz uzyskać dzięki narzędziom, kiedy to się stanie. Które oczywiście nie życzę nikomu.

Jest jeszcze kwestia do rozważenia w odniesieniu do wersjonowania: czy to prawda, że ​​2 różne pakiety (wbudowane w debugowanie i wydawanie) dzielą 1 numer wersji? SymbolSource zaakceptowałby to, ponieważ wyodrębnia pakiety i przechowuje pliki binarne w oddzielnych gałęziach kompilacji, JEDYNIE TYLKO NuGet może odpowiednio tagować pakiety. Nie ma obecnie możliwości określenia, czy pakiet jest debugowany, czy w trybie zwolnienia.

Answer 2

Przykład w pliku Creating and Publishing A Symbol Package odwołuje się do plików w katalogach debugowania jako źródła plików dll i pdb.

Określanie Symbol Zawartość opakowania

Pakiet symbol może być zbudowany przez konwencje, z folderu zorganizowany w sposób opisany w poprzednim rozdziale, lub jego zawartość może być określona za pomocą sekcji Pliki.Jeśli chciał budować przykładowy pakiet opisany poprzednio, można umieścić to w swoim nuspec pliku:

<files> 
    <file src="Full\bin\Debug\*.dll" target="lib\net40" /> 
    <file src="Full\bin\Debug\*.pdb" target="lib\net40" /> 
    <file src="Silverlight\bin\Debug\*.dll" target="lib\sl40" /> 
    <file src="Silverlight\bin\Debug\*.pdb" target="lib\sl40" /> 
    <file src="**\*.cs" target="src" /> 
</files> 

Ponieważ w celu publikowania symbole to, by inni mogli prześledzić kodu podczas debugowania, wydaje najbardziej rozważne jest opublikowanie wersji kodu przeznaczonej do debugowania bez optymalizacji, która mogłaby wpłynąć na krok po kroku.

Answer 3

Całkowicie zgadzam się z Twoim wnioskiem. Pakiety NuGet z RELEASE i SymbolSource z debugowaniem. Wydaje się dość rzadkie, aby wkroczyć bezpośrednio do pakietów, a okazjonalne błędy w debugowaniu z włączonymi optymalizacjami mogą być akceptowalne.

Jeśli był naprawdę problem, myślę, że idealnym rozwiązaniem byłoby wsparcie NuGeta. Wyobraźmy sobie na przykład, że podczas debugowania może zastąpić bibliotekę wydań DLL tą, która znajduje się w pakiecie SymbolSource.

Najlepiej byłoby wtedy, gdyby nuget pack SomePackage -Symbols przeciwko wersji wydania utworzyło pakiet Nuget wydania, ale pakiet symboli debugowania. Wtyczka VS zostanie zaktualizowana tak, aby była wystarczająco inteligentna, aby zobaczyć powiązanie i pobrać zestawy debugowania podczas działania w debugerze i załadować je. Coś szalonego, ale byłoby interesujące.

Jednak nie widzę wystarczająco wielu osób narzekających na to, że w tej chwili warto.

Zespół NuGet przyjmuje żądania ściągnięcia.:)