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

Ответ 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 и что угодно для каждого небольшого каталога.

Ответ 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. Один экземпляр каждого. Вы можете себе представить, сколько пространства на диске и времени потребляется для сборки, поскольку количество проектов и сложность зависимостей возрастает.

Ответ 3

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

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