Почему плохая практика распространять отладочную версию приложения в .NET?

Question

Чтение этот вопрос , в первом комментарии @Cody Grey говорит:

Хм, вы знаете, что вы не должны распространять версию "Debug",верно?

Я обеспокоен этим.В Visual Studio я обычно разрабатываю свои приложения в режиме отладки, и, если мне нужно распространить исполняемый файл, все, что я делаю, - это архив .exe и требуемых .dll файлов (в папке bin\Debug).

Почему это плохая идея?

В чем разница между выполнением этого и совершением аналогичных действий в режиме выпуска?

Редактировать:
Я спросилЭтот вопрос давным-давно, но я просто хотел отредактировать его, добавив разницу:

При использовании Debug.Assert в коде для тестирования и компиляции в Release Mode , все эти строкиушли, так что это может быть еще одно различие.

Answer 1

Это зависит от того, какой язык вы используете для разработки своей программы. Когда вы используете C ++, вы получаете издержки на / RTC и поддержку Edit + Continue. Они значительно замедляют сгенерированный код и повышают вероятность того, что ваше приложение рано или поздно выйдет из-под StackOverflow, если вы используете рекурсию. Исключения во время выполнения, которые вы можете получить из проверочного кода, трудно диагностировать без отладчика.

Если вы используете VB.NET, то при использовании отладочной сборки без отладчика у вас легко возникнет непоправимая утечка памяти. Недостаток в его коде поддержки Edit + Continue приводит к утечке WeakReference для каждого экземпляра класса, который содержит событие WithEvents. Ваше приложение в конечном итоге умирает по исключению OutOfMemory.

Если вы используете C #, значит, ни черта не идет не так, JIT-компилятор просто не может генерировать оптимизированный машинный код, а сборка мусора не так эффективна. Ваша программа будет работать медленно и потреблять больше памяти, чем необходимо. Это относится и к VB.NET и C ++ / CLI.

Perf обычно важен для программиста при написании кода. Таким образом, отгрузка отладочной сборки немного кощунственна. Однако значительное количество программ полностью блокируется вводом-выводом, диском, сетевой картой или сервером dbase. Сырой процессор не имеет большого значения в этом случае.

Answer 2

Существуют также юридические причины - Цитата: «Обратите внимание, что отладочные версии приложения не подлежат распространению и что ни одна из отладочных версий различных библиотек динамических ссылок (DLL) Visual C ++ не распространяется».Из Перераспределение приложений Microsoft Visual C ++ 6.0

И это для Visual Studio 2010 «Определение того, какие библиотеки DLL распространять»: «Вы не можете распространять все файлы, включенные в Visual Studio;разрешается только распространять файлы, указанные в Redist.txt. Отладочные версии приложений и различные библиотеки DLL Visual C ++ не подлежат распространению. От Определение того, какие библиотеки распространять

Answer 3

Чистое приложение на C # или VB.NET может работать на любом компьютере с установленным правильным перенаправлением .NET Framework, но приложению C ++ или C ++ / CLI (или смешанному приложению) необходим пакет перенаправления VC, который не содержит отладочные версии необходимых библиотек. Предполагая, что на ваших пользователях ПК Visual Studio не установлен, а только распространяемый пакет, я бы сказал, что вы рискуете, что отладочная версия вашей программы просто может там не работать.

Answer 4

Я думаю, что производительность - это проблема, В этом посте более подробно

Answer 5

Что касается производительности, мне было бы интересно увидеть некоторые метрики об отладке по сравнению с выпуском.

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