visual-studio - visual - package manager console create nuget package




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

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

  1. Удалять бинарные + пакеты контента только на nuget.org (или любой другой канал)
  2. Вставьте пакетный пакет debug + content в фид разработки:
    • на предпосылке
    • на myget.org
    • на nuget.org в качестве пакетов до выпуска.
  3. Нажимайте оба пакета релизов и отладки двоичных + символов на symbolource.org или в любое другое хранилище символов.

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

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

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

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

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

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

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

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

Таким образом, выбор:

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

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

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

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


Пример создания и публикации пакета 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>

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





nuget