Najlepsze rozwiązania dotyczące Nuget: debugowanie czy wydanie?

Obecnie pakuję kompilacje wydania z Nuget dla oficjalnych kompilacji do nuget.org, ale pakuję kompilacje debugowania z Nuget, aby źródło symboli wypychało do symbolsource.org.

EDYCJA: (Jon Skeet, z pewnym odchyleniem od rozwoju Noda Time)

NuGet obsługuje teraz wypychanie zarówno do galerii NuGet, jak i do symbolsource.org (lub podobnych serwerów), zgodnie z dokumentacją . Niestety istnieją tutaj dwa sprzeczne wymagania:

• Kiedy po prostu używasz biblioteki bez potrzeby debugowania, naprawdę potrzebujesz kompilacji wydania. W końcu do tego służą kompilacje wydań.
• Podczas debugowania w bibliotece w celach diagnostycznych naprawdę potrzebujesz kompilacji debugowania z wyłączonymi wszystkimi odpowiednimi optymalizacjami. W końcu do tego służą kompilacje debugowania.

Byłoby dobrze, ale NuGet nie (o ile wiem) nie pozwala na publikowanie zarówno wersji wydania, jak i kompilacji debugowania w użyteczny sposób, w tym samym pakiecie.

Mamy więc do wyboru:

• Roześlij wszystkim kompilacje debugowania (jak pokazano na przykładzie w dokumentacji) i żyj z dowolnymi rozmiarami i wynikami wydajności.
• Rozpowszechnij kompilacje wydania wszystkim i korzystaj z nieco ograniczonego środowiska debugowania.
• Wybierz naprawdę skomplikowaną politykę dystrybucji, potencjalnie zapewniającą oddzielne wydania i pakiety do debugowania.

Pierwsze dwie naprawdę sprowadzają się do efektu różnic między kompilacjami debugowania i wydania ... chociaż warto zauważyć, że istnieje również duża różnica między chęcią wejścia do kodu biblioteki, ponieważ chcesz sprawdzić pewne zachowanie, a chęcią aby debugować kod biblioteki, ponieważ uważasz, że znalazłeś błąd. W drugim przypadku prawdopodobnie lepiej jest pobrać kod biblioteki jako rozwiązanie Visual Studio i debugować w ten sposób, więc nie zwracam zbytniej uwagi na tę sytuację.

Moją pokusą jest pozostanie przy kompilacjach wydania, oczekując, że stosunkowo niewiele osób będzie musiało debugować, a optymalizacje w kompilacji wydania nie będą miały większego wpływu na tych, którzy to robią . (Kompilator JIT i tak wykonuje większość optymalizacji).

Czy są więc inne opcje, których nie rozważaliśmy? Czy są inne względy, które przechylają szalę? Czy wypychanie pakietów NuGet do SymbolSource jest na tyle nowe, że „najlepsze rozwiązanie” naprawdę nie zostało ustanowione?

W imieniu SymbolSource uważam, że najlepszą praktyką jest:

1. Wypychanie pakietów zawartości binarnej + wersji do witryny nuget.org (lub dowolnego innego źródła produkcyjnego)
2. Wypchnij pakiety debugowania binarnego + zawartości do źródła rozwoju:
   • lokalnie
   • na myget.org
   • na nuget.org jako pakiety w wersji wstępnej.
3. Wypchnij pakiety do wydania i debugowania binarnych + symboli do symbolsource.org lub dowolnego innego magazynu symboli.

Skoro już o tym mowa, powszechnym błędem jest przekonanie, że kompilacje do wydania i debugowania w .NET naprawdę bardzo się różnią, ale zakładam, że różnica jest tutaj z powodu różnych kodów, które mogą, ale nie muszą być zawarte w obu kompilacjach, takich jak Debug .Asserts.

To powiedziawszy, naprawdę warto wypchnąć obie konfiguracje do SymbolSource, ponieważ nigdy nie wiesz, kiedy będziesz musiał debugować kod produkcyjny. Zdalnie w produkcji, aby było trudniej. Będziesz potrzebować pomocy, jaką możesz uzyskać od narzędzi, gdy to się stanie. Czego oczywiście nikomu nie życzę.

Nadal jest kwestia do rozważenia w odniesieniu do wersjonowania: czy to poprawne, aby 2 różne pakiety (wbudowane w debugowanie i wydanie) miały jeden numer wersji? SymbolSource zaakceptuje to, ponieważ wyodrębnia pakiety i przechowuje pliki binarne w oddzielnych gałęziach trybu kompilacji, JEŚLI TYLKO NuGet może odpowiednio oznaczać pakiety. Obecnie nie ma możliwości określenia, czy pakiet jest w trybie debugowania, czy w trybie wydania.

Całkowicie zgadzam się z twoim wnioskiem. Pakiety NuGet z RELEASE i SymbolSource z debugowaniem. Wydaje się dość rzadkie wchodzenie bezpośrednio do pakietów, a okazjonalne błędy w debugowaniu z włączoną optymalizacją mogą być dopuszczalne.

Gdyby naprawdę był problem, myślę, że idealnym rozwiązaniem byłoby wsparcie NuGet. Na przykład wyobraź sobie, że podczas debugowania może zastąpić bibliotekę DLL wydania wersją zawartą w pakiecie SymbolSource.

Idealnie byłoby wtedy, nuget pack SomePackage -Symbolsgdyby wersja wydana utworzyła pakiet nuget wydania, ale pakiet symboli debugowania. Wtyczka VS zostanie zaktualizowana, aby była wystarczająco inteligentna, aby zobaczyć skojarzenie i pobrać zestawy debugowania podczas uruchamiania w debugerze i zamiast tego załadować je. Trochę szalone, ale byłoby interesujące.

Jednak po prostu nie widzę wystarczającej liczby osób narzekających na to, że w tej chwili byłoby to tego warte.

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

Minęło 8 lat od postu OP, więc spróbuję tego, co jest używane obecnie.

Istnieją dwa sposoby „wkraczania do ” pakietu NuGet:

1. Dystrybucja PDB

.symbols.nupkgPakiety symboli są uważane za starsze i zostały zastąpione .snupkgpakietami publikowanymi na serwerze Symbol Server . Jest obsługiwany przez wszystkich głównych dostawców, takich jak NuGet.org, Azure DevOps ( choć mniej płynne ) itp.

Oto oficjalne instrukcje . Po prostu dodaj te dwie linie do pliku csproj:

<PropertyGroup>
  <IncludeSymbols>true</IncludeSymbols>
  <SymbolPackageFormat>snupkg</SymbolPackageFormat>
</PropertyGroup>

Po stronie konsumenta upewnij się, że środowisko IDE jest skonfigurowane dla serwera symboli NuGet.org (lub platformy Azure itp.), Aby umożliwić przechodzenie do kodu pakietu podczas debugowania.

2. Link źródłowy. Łączenie z rzeczywistym kodem

W niektórych przypadkach PDB mogą ukrywać pewne szczegóły kodu źródłowego ze względu na optymalizację MSIL / JIT. Więc nie jest to sposób na” wchodzenie ” rzeczywistego źródła swojej Nuget podczas debugowania. Nazywa się Source Link z .NET Foundation - „ system niezależny od języka i kontroli źródła, zapewniający środowisko debugowania kodu źródłowego dla plików binarnych ”.

Jest obsługiwany przez Visual Studio 15.3+ i wszystkich głównych dostawców (obsługuje również prywatne repozytoria).

Konfiguracja jest banalna ( oficjalna dokumentacja ) - po prostu dodaj zależność programistyczną do pliku projektu (w zależności od typu repozytorium) wraz z kilkoma flagami:

<PropertyGroup>
    <PublishRepositoryUrl>true</PublishRepositoryUrl>
    <EmbedUntrackedSources>true</EmbedUntrackedSources>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.SourceLink.GitHub" Version="1.0.0" PrivateAssets="All" />
</ItemGroup>

Więcej informacji na ten temat można znaleźć w sekcji „ 5 kroków do ulepszenia pakietu NuGet ”.

Przykład w Tworzenie i publikowanie pakietu symboli odwołuje się do plików w katalogach debugowania jako źródeł plików dll i pdb.

Określanie zawartości pakietu symboli

Pakiet symboli można zbudować według konwencji, z folderu zorganizowanego w sposób opisany w poprzedniej sekcji, lub jego zawartość można określić za pomocą sekcji plików. Jeśli chcesz zbudować przykładowy pakiet opisany wcześniej, możesz umieścić to w swoim pliku nuspec:

<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ż celem publikowania symboli jest umożliwienie innym przechodzenia przez kod podczas debugowania, wydaje się najrozsądniejsze opublikowanie wersji kodu przeznaczonej do debugowania bez optymalizacji, które mogą mieć wpływ na przechodzenie kodu.