Почему в Visual Studio есть отдельные папки Debug и Release?

Question

Конечно, по умолчанию Visual Studio создает отдельные папки bin для сборок Debug и Release. У нас есть некоторые незначительные проблемы, связанные с ними с точки зрения внешних зависимостей, где иногда мы хотим выпускать двоичные файлы, а иногда отлаживать. Это сделало бы жизнь немного проще, если бы во всех проектах была одна папка bin и она была бы целью как для отладки, так и для выпуска. Затем мы можем указать наши внешние сценарии и т. Д. В одном месте.

Сотрудник спросил, почему мы не можем просто сделать это - изменить настройки проекта VS, чтобы перейти в ту же папку bin? Признаюсь, я не мог придумать вескую причину для их сохранения, кроме возможности легко увидеть в моей локальной файловой системе, что Debug, а какие Release. Ну и что; что это дает?

Мой вопрос (ы):

• Как использовать разные папки Debug и Release? Какие процессы это позволяет в вашей разработке?
• Что плохого может случиться, если вы не сможете сохранить это различие?
• И наоборот, если вы пошли по пути «одной папки», как это вам помогло?

Я НЕ спрашиваю, почему существуют отдельные сборки Debug и Release. Я понимаю разницу и место каждого. Мой вопрос касается размещения их в отдельных папках.

Answer 1

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

Answer 2

На мой взгляд, это просто удобство на машине разработчика, позволяющее им компилировать и запускать сборки Debug и Release одновременно.

Если у вас есть скрипты или инструменты, работающие внутри Visual Studio, IDE позволяет вам использовать ConfigurationName и другие макросы для получения путей, которые не зависят от конфигурации.

Если вы запускаете скрипты и инструменты извне из командной строки (т.е. вы структурируете какой-то процесс выпуска или развертывания вокруг него), лучше сделать это на сервере сборки, где проводится различие между Debug и Release уходит.

Например, когда вы вызываете msbuild из командной строки (на сервере сборки), вы можете указать свойство Configuration для Debug или Release и свойство OutputPath для сборки только в одном месте (независимо от конфигурации).

Answer 3

Одна из причин, по которой я использую отдельные папки, заключается в том, что это гарантирует, что я создаю только установщики, использующие код Release-build. Я использую WiX, который позволяет мне указать точный путь к файлам, которые я хочу включить в установщик, поэтому я в конечном итоге указываю путь в папке Release. (Конечно, вы можете сделать то же самое, используя обычные установщики VS, так что на самом деле это не главное.) Если вы забыли переключить проект на Release перед сборкой, установщик не соберется, если у вас нет старого кода в Release папка, в этом случае вы получите старый установщик, так что это немного ловушка. Чтобы обойти это, я использую событие post-build в проекте установщика WiX, которое очищает папку выпуска после сборки установщика WiX.

Answer 4

В предыдущей компании мы обошли эту проблему, изменив имена исполняемого файла отладки и dll, добавив «D». Так

MainProgram.exe & library.dll

стать

MainProgramD.exe & libraryD.dll

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

Очевидно, вам нужно изменить все ваши ссылки, чтобы они указывали на измененное имя для отладки - что вы забудете сделать в какой-то момент.

Answer 5

У меня есть опыт от более крупного проекта. Если существует несколько решений, использующих ссылки на файлы на другие решения, вы должны указать ссылку на ОДИН каталог, поэтому, очевидно, это должен быть «релиз» для непрерывной / ночной сборки. Теперь вы можете представить, что произойдет, если разработчик захочет работать с отладочными версиями - все ссылки указывают на релизные. Если бы он указывал на один и тот же каталог, переключение на отладку было бы только вопросом перекомпиляции всех связанных вещей в режиме отладки, и ссылки на файлы автоматически указывали бы на версии отладки с тех пор.

С другой стороны, я не вижу смысла в том, почему разработчик захочет работать с релизными версиями (и переключаться туда-сюда) - режим релиза полезен только для полной / ночной сборки, поэтому решения в VS может оставаться по умолчанию в режиме отладки, а скрипт сборки (в любом случае) всегда очищает, выпускает сборку.

Answer 6

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

Answer 7

Иногда можно столкнуться с особенно неприятной проблемой неинициализированной памяти, которая возникает только при сборке релиза. Если вы не можете поддерживать (как предполагает ChrisF) отдельные имена для своих двоичных файлов отладки и выпуска, очень легко потерять отслеживание того, какой двоичный файл вы используете в настоящее время.

Кроме того, вы можете настроить параметры компилятора (т. Е. Уровень оптимизации, символы выпуска с отладкой для упрощения профилирования и т. Д.), И гораздо проще поддерживать их в порядке в отдельных папках.

Однако все зависит от личных предпочтений, поэтому Visual Studio позволяет легко изменять параметры.

Answer 8

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

И не забывайте о человеческом аспекте: гораздо легче узнать, с чем вы работаете (и исправить поврежденные сборки), если две сборки выводят в разные места.

Answer 9

Быть последовательным в своих сборках - это хорошо. Вы не хотите иметь дело с проблемами, связанными с условной компиляцией и т. Д. где ваши dll выпуска и отладки несовместимы, но вы пытаетесь запустить их друг против друга.

Answer 10

Visual IDE IDE работает, что лучше для толпы. Они создают структуру проекта по умолчанию, бинарные папки. Вы можете отобразить двоичные файлы в одну папку. Затем вам нужно сообщить другим разработчикам, что файлы Release / Debug хранятся в той же папке.

Разработчики спросят вас, кто вам так нравится?

В VC ++ у нас созданы разные библиотеки, и вам нужно связать соответствующие версии. В противном случае вы получите ошибку компоновщика.