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

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

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

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

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

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

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

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

MainProgram.exe и library.dll

стать

MainProgramD.exe и библиотекаD.dll

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

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

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

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

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

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

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

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

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

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

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

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

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

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