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

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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

В предыдущей компании мы столкнулись с этой проблемой, изменив имена исполняемых файлов debug и dll, добавив "D". Так

MainProgram.exe и library.dll

стать

MainProgramD.exe и libraryD.dll

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

Все это зависит от личных предпочтений - вот почему Visual Studio упрощает изменение параметров.

Ответ 8

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

Разработчики спросят вас, кто вы так любите?

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

Ответ 9

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

Ответ 10

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

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