Разработчики используют Visual Studio (VS) GUI для разработки своих решений и создания своих проектов с использованием файла решения (.SLN). Затем команды сборки, использующие vNext, должны автоматизировать эти сборки, используя MSBuild вместо devenv.exe (исполняемый файл Visual Studio). Это серьезная и хроническая проблема c, поскольку MSBuild не только не способен создавать несколько типов проектов, но и порядок сборки определяется совершенно другим и сложным способом.
Некоторые рекомендации Microsoft (https://docs.microsoft.com/en-us/archive/blogs/msbuild/incorrect-solution-build-ordering-when-using-msbuild-exe) - переключение на явные зависимости в каждом файле. * Proj и удаление всех спецификаций зависимостей в файле .SLN. Это звучит как человек, который никогда не работал в относительно беспомощной сборочной команде, пытающейся заставить команды разработчиков:
- делать большую часть того, что они считают пустой тратой времени, и
- изменить способ работы
Команды, работающие над сборкой, нуждаются в способе автоматизации любого VS, позволяющего создавать команды разработчиков. Если VS предоставляется SLN для сборки, тогда сборка vNext должна иметь возможность использовать тот же SLN таким же образом. Вместо этого vNext в настоящее время предлагает только MSBuild в качестве инструмента для сборки. У MSBuild гораздо больше опций, чем у devenv, так что было бы замечательно, ЕСЛИ можно было бы использовать SLN для управления зависимостями так же, как VS, и он был бы модернизирован для построения всех типов проектов.
Были предприняты потенциальные усилия, на которые ссылается PatrickLu-MSFT по адресу Проект сборки с использованием devenv.exe в TFS 15RC1 Build Server , чтобы усовершенствовать шаг сборки vNext, чтобы позволить использовать devenv вместо MSBuild, но эти усилия Кажется, что он был отброшен.
Может быть, кто-то разработал пользовательский шаг сборки vNext для сборки с использованием devenv?