Здравствуйте, rosencrantz, Вы писали:

R>Насколько велико должно быть желание?

Примерно такое же, как в случае с Maven. Только там заставят и придётся этим заниматься, а в .NET велика вероятность, что и не понадобится никуда руками лазить, всё из коробки работать будет.

R>Я смотрю на проект ~2015 года — зависимости из нугета лежат в packages.config, а в *.csproj — ссылки на конкретные assemblies. Я припоминаю, что одно время когда в студии открываешь солюшн, там надо было руками что-то нажать, чтобы пакеты скачались. Потом вроде появилась какая-то галочка "скачивать автоматически".

Можно было в csproj прописать Target, который это автоматом перед сборкой делал.

R>Разница в культуре. В Gradle/Maven есть плагины — их много, они сами скачиваются и работают. В MSBuild, как ты сам сейчас продемонстрировал, "этого нет, но ведь оно и не надо".

У .NET нормальные шаблоны и та же Visual Studio успешно делает грязную работу по редактированию csproj.
Большинство проектов собирается на этом шаблонном проекте и ничего хитрого им не нужно.
maven и gradle с самого начала в это всё окунают и барахтайся как хочешь.
Мне тут больше нравится подход .NET и всего смежного. Начинающий разработчик и ничего хитрого не мудришь — тыкай кнопки в GUI и всё будет работать.
Понадобилось что-то эдакое изобразить — погружайся в xml и изучай всё это добро.

R>А почему в Microsoft мире на это меньше загоняются? Было бы интересно разобраться, почему большинство задач решается в 2 клика — то ли потому что у Микрософт инструменты сборки такие мощные, то ли потому что инструменты плохие, но об этом все знают — и поэтому никому даже в голову не приходит решить более-менее сложную задачу (которая в том же Gradle будет просто "обычной")

Берём C# и Visual Studio. Просто создаёшь Solution, в нём нужные проекты, между проектам проставляешь взаимосвязи. Нажимаешь F5, всё собралось и запустилось (сборка основного проекта вызовет сборку тех проектов, от которых он зависит, артефакты скопируются в выходную папку и т.д.).
Ноль телодвижений и изучения xml или ещё чего, в два клика в GUI настроилось и работает интуитивно понятно.
То же самое изобразить в maven — придётся статью-другую прочитать и разобраться как сделать корневой pom.xml и
прикрутить к нему pom.xml от проектов и как-то связи между проектами проставить.
Даже hello world вынудит лезть в xml и разбираться что там и как работает.
Опять же, вопрос в выбранном использовании инструментов. Можно в MSBuild всю сборку и деплой засунуть.
Можно оставить только базовую сборку, а разные варианты развёртывания уже в CI реализовать в виде скриптов каких-нибудь.
С maven и другими вопрос такой же. Ну, есть для него плагин для flyway, можно через mvn миграцию БД сделать.
Только куча людей скажет, что это идиотизм, так не надо делать и плагин этот не нужен.

R>А что именно смущает? Слово "Maven" в названии репозитория?

что сборка привязана к репозиторию и транспорту по сути.
На локальной машине у меня могут быть одни настройки, может у меня локальный репозиторий или какой-нибудь собственный, но доступный по адресу 192.168.0.1.
В CI тот же самый репозиторий мне может доступен по адресу 10.0.0.1.
Вместо того, чтобы настроить транспорт для пакетов, мне нужно городить конфиг сборки, где всё это учитывать, заводить разные профили и т.д.