Это можно сделать, просто используя переключатель MSBuild --output и указав папку для всех выходных данных при создании проекта / решения. Все зависимые проекты и т. Д. 1011 * будут собраны и скопированы в одну выходную папку.
Не думаю, что это особенно актуально для «уменьшения количества копируемых файлов» - жесткие диски копируют файлы весь день , ежедневно. Вывод в одну папку может иметь преимущество при упаковке для выпуска; наш сервер сборки Jenkins объединяет все файлы в одну папку перед тем, как поместить их в файл пакета (zip) для развертывания Octopus
Вам необходимо быть осторожным, поскольку разные проекты могут зависеть от разных версий одна и та же DLL, и, объединяя все файлы в одну папку, DLL с одинаковым именем (но другой версии) перезаписывают друг друга. Затем вы можете столкнуться с ситуацией, когда ваше приложение не загружается, потому что оно пытается найти XYZ DLL версии 1.0, а какой-то другой проект ссылается на версию 1.1, а поскольку этот проект создан позже, это версия DLL DLL 1.1, которая заканчивается в папке. После этого вы можете столкнуться с ошибками во время выполнения, указывающими на то, что «определение манифеста обнаруженной сборки не совпадает со ссылкой на сборку» - это говорит: «Я искал 1.0, я нашел DLL с правильным именем, но найденная версия была 1.1».
Обычно это можно решить с помощью перенаправления привязки, но это не на 100% гарантирует, что будущие версии DLL обратно совместимы с более ранними версиями. Если вы упорядочиваете все свои библиотеки DLL для копирования в одну папку, вы создаете для себя небольшую лотерею относительно того, что произойдет сбоем в работе, когда версии DLL go не совпадают c с тем, что вы ожидаете
Если ваша компания использует процесс компоновки и развертывания, который использует локально скопированные версии библиотек DLL, возможно, они настаивают на том, чтобы вы скопировали все библиотеки DLL в одну папку, чтобы доказать, что приложение будет работать в рабочем режиме - это гораздо более веская причина (то есть, чтобы вы могли сломать сервер dev, чтобы вы могли видеть и устранять проблемы, вызванные версиями DLL, перед тем, как запускать их в производство и запускать те же самые), чем «потому что мы не хотим, чтобы жесткий диск устал от копирования дополнительных файлов»