Просто, чтобы сделать это более понятным для меня, я хотел бы спросить вас, ребята, правильное условие (ы), чтобы иметь
проект или решение Перестроить вместо сборки в Visual Studio?
Если я перефразирую его: зачем MS необходимо создать опцию "Re-build ALL" в Visual Studio? Каков был их главный мотив сделать это?
Спасибо!
DRY: Rebuild = Clean + Build для каждого проекта по очереди.
Сборка не удаляет предыдущие выходы сборки. Rebuild удаляет их и снова создает (один проект за раз, если вы в решении: delete proj1\bin\Debug, build proj1, delete proj2\bin\Debug...).
Основной случай, когда я выполняю перестройку (или чистую сборку), - это когда мне нужно обновить третьи зависимости решения. Посмотрим на следующее дерево папок:
SOLUTION
|__Dependencies
|__PROJ_1
|__bin
|__obj
|__(code)
|__PROJ_2
|__bin
|__obj
|__(code)
Если я изменю свои DLL файлы в Dependencies и не буду делать пересоединение, VS (и MsBuild) будут использовать предыдущую версию dll, которая находится в PROJ_N\bin\Debug (или в bin\Release), из-за зависимости порядок поиска (см. http://www.beefycode.com/post/Resolving-Binary-References-in-MSBuild.aspx):
{CandidateAssemblyFiles}$(ReferencePath) - свойство ссылочного пути, которое поступает из файла .USER.{HintPathFromItem}. DLL в папке bin попадает в первый регистр, dll в папке Dependencies появляется во втором случае...
В таком случае я бы сделал чистую (отладочную), чистую (Release), а затем сборку, чтобы уничтожить всю предыдущую версию в папке bin. Я, может быть, немного перехитрил, и пересоздания может быть достаточно, но я не уверен, потому что DLL находятся в Debug и в папках Release...
Иногда все идет не так, и сборка просто не работает.
Это происходит, например. когда я неправильно обновляю зависимые библиотеки, которые затем неправильно копируются в пути bin сборки. Существуют другие примеры, не относящиеся к spring.
Это, когда я использую rebuild.