Изменение пути вывода сборки Visual Studio по умолчанию

Question

Есть ли веские причины для изменения пути вывода сборки вашего проекта по умолчанию по умолчанию "bin \ debug"? Есть ли какая-то польза от направления всех ваших проектов в рамках одного решения на общее расположение вывода?

Answer 1

Да, я обычно делаю это все время . Как сказал Гарри, это уменьшает использование дискового пространства. Это действительно не имеет большого значения для меня, так как дисковое пространство невероятно дешево, но это может быть проблемой для вас. Настоящая причина, по которой я это делаю, заключается в том, чтобы лучше отразить, как будет выглядеть развертывание. Лучший способ сделать это - иметь лист свойств , который изменяет каталог вывода на $(SolutionDir)/build/bin. После этого я установил для рабочего каталога $(SolutionDir)/build, то есть всю структуру, которая идентична той, которая будет развернута, а не распределена по различным каталогам проектов.

build
|-- bin
|   |-- foo.exe
|   |-- libfoo.dll
|   `-- libbar.dll
|-- plugins
|   |-- extender.py
|   `-- something.lua
`-- skins
    |-- default.skin
    `-- white-and-gold.skin

В целом, наличие изолированного каталога для создаваемых вещей (а не исходников) - это хорошо. Это облегчает написание пользовательских шагов сборки, поскольку вы знаете, где будет конечный результат, и облегчает интеграцию с вашей системой управления версиями, поскольку вы можете просто настроить его на игнорирование всего этого каталога, вместо того, чтобы обойти установку ignore для всех .exe , .lib, .so, .dll и все, что угодно для каждого маленького каталога.

Answer 2

Основная причина, по которой я меняю свой выходной каталог, заключается в том, чтобы сократить количество дублирующихся сборок и количество копий файлов, которые должна создать Visual Studio. Если проект A ссылается на проект B, а проект C ссылается на проект A и B, то Studio необходимо построить A, скопировать A в B и построить B, затем скопировать A и B в C и построить C. Теперь у вас есть 3 копии сборки A, две копии сборки B и одна из C. Указывая выходные данные в один каталог, Visual Studio просто создает A, затем B, затем C. Одна копия каждого. Вы можете представить, сколько больше дискового пространства и времени затрачивается на сборку по мере роста числа проектов и сложности зависимостей.

Answer 3

В качестве примера у меня есть файл Updater.exe, который должен распространяться вместе с «другой» программой. Поэтому я установил путь сборки для пути сборки других программ. Таким образом, я знаю, что у меня всегда есть последний "updater.exe", где он должен быть.

Это только одна причина.