Лучшие практики с Nuget: отладка или выпуск?

В настоящее время я упаковываю сборки релизов с помощью Nuget для официальных сборок на nuget.org, но я упаковываю сборки отладки с помощью Nuget, чтобы источник символов подталкивал к symbolource.org.

EDIT: (Джон Скит, с некоторым уклоном от разработки Noda Time)

Теперь NuGet поддерживает нажатие как галереи NuGet, так и symbolource.org(или аналогичных серверов) как описано в документе. К сожалению, здесь есть два противоречивых требования:

Когда вы просто используете библиотеку без необходимости отладки, вам действительно нужна сборка релиза. В конце концов, для чего нужны версии для сборки.
При отладке в библиотеке для целей диагностики вам действительно нужна отладочная сборка с отключенными всеми оптимизационными оптимизациями. То, что для сборки отладки, в конце концов.

Это было бы хорошо, но NuGet (насколько я могу судить) не позволяет опубликовать как выпуск, так и debug-сборки в полезном виде в том же пакете.

Итак, выбор:

Распределите сборки отладки для всех (как показано в примере в документах) и живите с любым размером и производительностью.
Распространяйте сборку релизов для всех и живите с немного ослабленным опытом отладки.
Перейдите к действительно сложной политике распространения, потенциально предоставляя отдельные пакеты выпуска и отладки.

Первые два действительно сводятся к влиянию различий между сборками debug и release... хотя стоит отметить, что существует также большая разница между желанием вступить в код библиотеки, потому что вы хотите проверить какое-то поведение, и хотите отладить код библиотеки, потому что вы считаете, что обнаружили ошибку. Во втором случае, вероятно, лучше получить код библиотеки в качестве решения Visual Studio и отладить этот путь, поэтому я не уделяю слишком много внимания этой ситуации.

Мое искушение состоит в том, чтобы просто поддерживать сборку релизов, ожидая, что относительно мало людей придется отлаживать, а те, кто это делает, не будут сильно влиять на оптимизацию в сборке релизов. (В любом случае компилятор JIT делает большую часть оптимизации.)

Итак, есть ли другие варианты, которые мы не рассматривали? Есть ли другие соображения, которые подсказывают баланс? Является ли толкание пакетов NuGet на SymbolSource достаточно новым, что "наилучшая практика" действительно не установлена?

Ответ 1

Говоря о SymbolSource, я считаю, что наилучшая практика заключается в следующем:

Push релиз двоичный + контент пакеты только на nuget.org(или любой другой канал)
Вставьте файлы с двоичным содержимым + содержимое в фид разработки:
- на предпосылке
- на myget.org
- на nuget.org в качестве пакетов перед выпуском.
Нажимайте оба пакета выпуска и отладки двоичных + символов на symbolource.org или в любое другое хранилище символов.

Пока мы находимся в этом, это распространенное заблуждение, что выпуски и отладки сборки в .NET действительно сильно отличаются друг от друга, но я предполагаю, что дифференциация здесь из-за различного кода, который может быть или не быть включен в сборку, например Debug.Asserts.

Тем не менее, действительно стоит подталкивать обе конфигурации к SymbolSource, потому что вы просто не знаете, когда вам понадобится отладить производственный код. Удаленно в производстве, чтобы сделать его сложнее. Когда это случится, вам понадобится помощь, которую вы можете получить от своей инструментальной системы. Который я, очевидно, никому не желаю.

Есть еще вопрос, который следует учитывать в отношении управления версиями: правильно ли иметь 2 разных пакета (встраивать в отладку и в выпуске), используя один номер версии? SymbolSource согласился бы с этим, поскольку он извлекает пакеты и хранит двоичные файлы в отдельных ветвях режима построения, ЕСЛИ ТОЛЬКО NuGet разрешает соответствующим образом маркировать пакеты. В настоящее время нет способа определить, является ли пакет отладочным или деблокированным.

Ответ 2

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

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

В идеале, что произойдет тогда, что nuget pack SomePackage -Symbols от версии релиза создаст пакет nuget для выпуска, но пакет отладочных символов. И плагин VS будет обновлен, чтобы быть достаточно умным, чтобы видеть связь и втягивать сборки Debug при запуске в отладчике и загружать их. Вид сумасшедший, но будет интересно.

Тем не менее, я просто не вижу достаточного количества людей, жалующихся на это, что в данный момент это стоит того.

Команда NuGet принимает запросы на загрузку.:)

Ответ 3

Пример в Создание и публикация пакета Symbol ссылается на файлы в каталогах Debug в качестве источников для файлов 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>

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