Найкращі практики з Nuget: налагодження чи випуск?

92

На даний момент я пакую збірки випусків з Nuget для офіційних збірок на nuget.org, але я налагоджую збірки налагодження з Nuget для джерела символів, що надсилає до symbolsource.org.

EDIT: (Джон Скіт, з деяким упередженням від розробки Noda Time)

NuGet тепер підтримує штовхаючи як до NuGet галереї і symbolsource.org (або аналогічних серверів), як описано . На жаль, тут є дві суперечливі вимоги:

  • Просто використовуючи бібліотеку без налагодження, ви дійсно хочете побудувати випуск. Зрештою, для цього призначені збірки випусків.
  • При налагодженні бібліотеки з діагностичною метою ви дійсно хочете побудувати налагоджувальну систему з вимкненими всіма відповідними оптимізаціями. Зрештою, для цього і потрібні збірки налагодження.

Це було б непогано, але NuGet (наскільки я можу зрозуміти) не дозволяє публікувати як збірки випусків, так і налагодження корисним способом, в одному пакеті.

Отже, вибір:

  • Поширюйте налагоджувальні збірки всім (як показано в прикладі в документації) і живіть із будь-якими розмірами та показниками продуктивності.
  • Поширюйте збірки випусків серед усіх і живіть зі слабким досвідом налагодження.
  • Виберіть дійсно складну політику розповсюдження, яка потенційно надає окремі пакети випуску та налагодження.

Перші два справді зводяться до ефекту різниці між збірками налагодження та випуску ... хоча варто зазначити, що існує також велика різниця між бажанням зайти в код бібліотеки, тому що ви хочете перевірити деяку поведінку, і бажанням для налагодження коду бібліотеки, оскільки ви вважаєте, що знайшли помилку. У другому випадку, мабуть, краще отримати код бібліотеки як рішення Visual Studio і налагодити таким чином, тому я не надто прислухаюся до цієї ситуації.

Я маю спокусу просто продовжувати збірки випусків, сподіваючись, що відносно мало людей потребуватиме налагодження, а ті, хто це зробить, не будуть сильно впливати на оптимізацію збірки випусків. (Компілятор JIT все одно робить більшу частину оптимізації.)

Отже, чи є інші варіанти, які ми не розглядали? Чи існують інші міркування, які схиляють до ваги? Чи надсилання пакетів NuGet до SymbolSource є настільки новим, що "найкраща практика" насправді не була створена?

visual-studio  debugging  release  nuget 
— гзак
джерело
2
Я збирався задати те саме запитання - хоча в даний час я також надсилаю конфігурацію випуску до джерела символів, враховуючи те, що я просто використовую nuget pack ... -Symbolта штовхаю згенеровані пакети ...
— Джон Скіт,
1
Я відчуваю, що я мав би представити цю сесію запитань людям, які стоять за NuGet, і подивитися, чи зможуть вони на це зважити.
— гзак
Спічіть вхід у свій пакет, а потім опублікуйте лише збірку випуску. Ви можете дозволити введення реєстратора, який надасть споживачеві змогу налаштувати ведення журналу відповідно до своїх уподобань.
— CShark

Відповіді:

31

Говорячи для SymbolSource, я вважаю, що найкращою практикою є:

  1. Надішліть пакунки двійкового вмісту + вмісту лише на nuget.org (або будь-який інший канал)
  2. Надішліть налагоджувальні двійкові пакети вмісту до стрічки розробки:
    • на передумові
    • на myget.org
    • на nuget.org як пакети попередньої версії.
  3. Надішліть пакети двійкових символів + для випуску та налагодження на сайт symbolource.org або будь-який інший магазин символів.

Поки ми до цього прийшли, загальноприйнятою помилкою є те, що збірки випусків та налагодження у .NET дійсно сильно відрізняються, але я припускаю, що диференціація тут пов’язана з різним кодом, який може або не може бути включений в будь-яку збірку, наприклад, налагодження .Твердження.

Тим не менш, насправді варто перенести обидві конфігурації на SymbolSource, оскільки ви просто ніколи не знаєте, коли вам потрібно буде налагоджувати робочий код. Віддалено на виробництві, щоб ускладнити. Коли це станеться, вам знадобиться допомога, яку ви зможете отримати від свого інструментарію. Якого я, очевидно, не бажаю нікому.

Щодо розробки версій все-таки слід врахувати питання: чи правильно мати два різних пакети (вбудований та налагоджений та спільний), що мають 1 номер версії? SymbolSource прийняв би це, оскільки він витягує пакунки та зберігає двійкові файли в окремих гілках режиму побудови, ЯКЩО ТІЛЬКИ NuGet дозволить відповідним чином позначати пакунки. В даний час неможливо визначити, налагоджений пакет чи режим випуску.

— TripleEmcoder
джерело
Частина "публікація двох збірок до NuGet" - це хитрий біт. Я завжди публікував збірку випуску Noda Time на тій підставі, що мені доводилося вибирати між ними. (У мене є файл nuspec, а не просто з проекту C #.) Ви згадуєте про налагодження виробничого коду так, ніби це значно складніше лише при побудові випуску - незважаючи на попередню частину "вони не сильно відрізняються". Мені відомо про NOP у збірках налагодження, і, очевидно, Debug.Assertтощо - але чи можете ви розширити (у вашій відповіді) наслідки під час налагодження? Наскільки це погано за допомогою побудови випуску?
— Джон Скіт,
Я мав на увазі лише те, що ви хочете, щоб символи були доступні для всіх використовуваних двійкових файлів: якщо в дикій природі є як збірки налагодження, так і випуску, ви хочете надати символи для обох. Їм не потрібно сильно відрізнятися з точки зору коду, але вони будуть відрізнятися в контрольних сумах, що робить завантаження символів неможливим без певного злому.
— TripleEmcoder
1
Правильно. Моє можливе рішення - це лише коли-небудь випускати бінарні файли Release, але я стурбований тим, наскільки це зашкодить з точки зору налагодження. Наприклад, чи означає відсутність NOP неможливість додавання точок зупинки?
— Джон Скіт,
Проблема полягає в оптимізації JIT, а не в оптимізації часу побудови. Отже, якщо ви натискаєте пакети в режимі випуску та рекомендуєте використовувати COMPLUS_ZapDisable = 1, коли потрібна налагодження, це буде для мене досить добре. Все-таки NuGet повинен дозволити налагодження та випуск разом якимось чином.
— TripleEmcoder
Я навіть не підозрював, що symbolssource.org існує. Як свербіж, який мені неодноразово потрібно було почухати, я вітаю його.
— Remus Rusanu
4

Я повністю згоден з вашим висновком. Пакети NuGet з RELEASE та SymbolSource з налагодженням. Здається, досить рідко можна переходити безпосередньо до пакетів, і випадкові помилки налагодження з увімкненою оптимізацією можуть бути прийнятними.

Якби дійсно існувала проблема, я вважаю, що ідеальним рішенням буде підтримка NuGet. Наприклад, уявіть, що при налагодженні він може замінити випуск DLL на той, що входить до пакета SymbolSource.

В ідеалі, що трапиться тоді, це те, що nuget pack SomePackage -Symbolsпроти версії випуску буде створений пакет nuget випуску, але пакет символів налагодження. І плагін VS буде оновлений, щоб бути достатньо розумним, щоб бачити асоціацію та втягувати збірки налагодження під час роботи в налагоджувачі та завантажувати їх. Начебто божевільний, але було б цікаво.

Однак я просто не бачу достатньої кількості людей, які б скаржились на це, що на даний момент це того варте.

Команда NuGet приймає запити на витягування. :)

— Зламаний
джерело
Я не впевнений, що розумію ваше друге речення - я підозрюю, що OP (до мого редагування) виконував ручні натискання на SymbolSource для побудови налагодження. Чи є передбачити суттєві проблеми , якщо в Випуску створення версії PDB закінчується в SymbolSource замість налагоджувальної версії? Або це ви захищали, а я просто неправильно зрозумів?
— Джон Скіт,
3
"Однак я просто не бачу достатньої кількості людей, які б скаржились на це, що на даний момент це того варте". Можливо, вони не скаржаться, але якби ви запитали вибірку користувачів, що вони думають про це, я б впевнений, що більшість людей визнають трохи плутанини на цьому конкретному кроці (що опублікувати на NuGet.org та SymbolSource .org). Якби ви запитали, що вони закінчили вибирати, ви, мабуть, виявили б, що єдиної узгодженої практики не існує, кожен просто робить свою справу.
— gzak
7
Я хочу поскаржитися на це, де я можу зареєструватися?
— Олексій
Після того, як у вас є внутрішній NuGets, і ви починаєте їх розгортати на сервері символів ... ви неминуче захочете їх налагодити .... і навіть незважаючи на те, що ви можете перейти через код, ви отримаєте "Не вдається отримати значення локальна змінна або аргумент ... її було оптимізовано ". Як згадує Філ ... ЯКЩО nuget мав спосіб завантажувати налагоджувальні DLL-файли в режимі налагодження та випускати DLL-файли в режимі звільнення (з пакунків Nuget), це було б остаточним. До цього часу ми застрягли з перемикачем пакетів
— Nuget
1
Я згоден, це було б непоганим вдосконаленням продукту.
— htm11h
2

З моменту публікації ОП минуло 8 років, тож я розберуся з тим, що використовується сьогодні.

Існує 2 способи « вступити » в пакет NuGet:

1. Поширення PDB

.symbols.nupkgпакети символів розглядаються як застарілі і були замінені .snupkgпакетами, які публікуються на сервері Symbol . Це підтримується усіма основними постачальниками, такими як NuGet.org, Azure DevOps ( хоча і менш плавні ) тощо.

Ось офіційні інструкції . Просто додайте ці два рядки у файл csproj:

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

З боку споживача переконайтеся, що ваша IDE налаштована на сервер символів NuGet.org (або Azure тощо), щоб дозволити входити в код пакета під час налагодження.

2. Посилання на джерело. Посилання на фактичний код

У деяких випадках PDB можуть приховувати деякі особливості вихідного коду завдяки оптимізації MSIL / JIT. Таким чином , є спосіб » заходячи в " фактичний джерело вашої NuGet у час налагодження. Це називається Source Link від .NET Foundation - " агностична система управління мовами та джерелами для забезпечення досвіду налагодження джерел для двійкових файлів ".

Це підтримується Visual Studio 15.3+ та усіма основними постачальниками (також підтримує приватні репозиторії).

Налаштування тривіальне ( офіційні документи ) - просто додайте залежність розробки до файлу проекту (залежить від типу вашого репо) разом з деякими прапорцями:

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

Докладніше про цю тему див. У " 5 кроках до кращого пакета NuGet ".

— Алекс Клаус
джерело
1

Приклад створення та публікації пакета символів посилається на файли в каталогах налагодження як джерела для файлів dll та pdb.

Вказівка ​​змісту пакета символів

Пакет символів може бути побудований за домовленостями з папки, структурованої так, як описано в попередньому розділі, або його вміст можна вказати за допомогою розділу файлів. Якщо ви хочете створити приклад пакета, описаний раніше, ви можете помістити це у свій файл 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>

Оскільки мета публікації символів - дозволити іншим переходити через ваш код під час налагодження, видається найбільш розумним опублікувати версію коду, призначену для налагодження, без оптимізацій, які можуть вплинути на покроковий процес.

— tvanfosson
джерело
Так, це те, що робить приклад - але я б волів, щоб у кінцевому підсумку не з’явилася можливість налагоджувати, перекриваючи бажання більшості розробників просто запустити реліз-версію. Проблема полягає в тому, що NuGet не має можливості публікувати як випуски, так і збірки налагодження, наскільки я можу зрозуміти. (Мені також було б трохи боляче опублікувати обидва, оскільки це означає створення ще одного набору конфігурацій для підписаних збірок налагодження ...)
— Джон Скіт,
Тут ми потрапляємо в трохи суб’єктивності. Як правило, моїм вибором "найкращої практики" буде той, який автор рекомендує, явно чи неявно, оскільки я припускаю, що вони мають більше розуміння (або контролю у випадку припущень, які закінчуються прикладами), ніж I. Якщо говорити особисто, Я думаю, що символи повинні відповідати версії, яку я використовую. Зазвичай я не використовував би пакет, який, на мою думку, мені напевно довелося б налагодити, якщо тільки джерело не було загальнодоступним, і я б міг компілювати з нуля, якщо це необхідно, тому відсутність упакованої збірки налагодження не є особливо важливою.
— tvanfosson
У моєму випадку, якщо комусь потрібно налагодити Noda Time, оскільки він вважає, що в Noda Time є помилка, їм краще завантажити джерело (що, звичайно, вони можуть зробити). Однак корисно мати можливість зайти у вихідний код Noda Time лише для того, щоб побачити, що відбувається. В основному, я думаю, що існує (принаймні) два різні сценарії налагодження з різними рішеннями ...
— Джон Скіт,
Одне, про що я люблю думати, це сам .NET: я думаю, можна з упевненістю сказати, що Microsoft публікує збірки випусків, а не налагоджує збірки .NET. Збірка випуску передбачає певний рівень якості та стабільності, тому ідея полягає в тому, що вам рідко потрібно заходити в код, щоб діагностувати речі.
— gzak
2
Однак це також досить ментальність "закритого джерела". Я виявив, що у світі з відкритим кодом більше очікується можливість входити в код "стабільних випусків" різних бібліотек не тому, що речі зламані, а тому, що іноді найкращою документацією є просто подивитися, що таке бібліотека робити.
— гзак
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.