Изменение значения по умолчанию Visual Studio создает выходной путь
Там какие-либо серьезные основания состоят в том, чтобы изменить выходной путь сборки Вашего проекта от его значения по умолчанию "bin\debug"? Там какое-либо преимущество к указанию на все Ваши проекты в решении общего выходного местоположения сборки?
3 ответа
Да, я обычно делаю это все время . Как сказал Гарри, это уменьшает использование дискового пространства. Для меня это не имеет большого значения, поскольку дисковое пространство невероятно дешево, но это может быть проблемой для вас. Настоящая причина, по которой я делаю это, чтобы лучше отразить то, как будет выглядеть развертывание. Лучший способ сделать это - иметь страницу свойств , которая изменяет выходной каталог на $ (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
В целом, наличие изолированного каталога для вещей, которые собираются (а не исходных текстов), - это хорошо.Это упрощает написание пользовательских шагов сборки, поскольку вы знаете, где будет конечный результат, и упрощает интеграцию с вашей системой управления версиями, поскольку вы можете просто настроить ее на игнорирование всего каталога, вместо того, чтобы обходить настройку игнорировать для все .exe , .lib , .so , .dll и все, что угодно для каждого маленького каталога.
Основная причина, по которой я меняю выходной каталог, - это сократить количество повторяющихся сборок и количество копий файлов, которые 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. По одной копии каждой. Вы можете себе представить, сколько места на диске и времени уходит на сборку по мере роста количества проектов и сложности зависимостей.
В качестве примера у меня есть updater.exe, который должен распространяться вместе с "другой" программой. Поэтому я устанавливаю путь сборки на путь сборки "другой" программы. Таким образом, я знаю, что всегда имею последнюю версию "updater.exe" там, где она должна быть.
Это только одна из причин.