Почему нет необходимости в Maven в .NET?

Ответ 1

Для разрешения зависимостей артефакта я бы сказал, что Nuget теперь является предпочтительной альтернативой. Он поддерживает и поддерживает разрешение времени сборки, то есть нет необходимости проверять артефакты бинарных зависимостей на vcs. См. эти статьи.

Начиная с версии 2.7 Nuget, временное разрешение сборки имеет еще лучшую поддержку с помощью команды Nuget restore, являющейся одним из параметров.

Update: В настоящее время существует альтернативный доступный менеджер пакетов с поддержкой nuget - Paket, который лучше, чем клиент ванильного nuget при обработке временных зависимостей и гармонизации зависимостей между проектов в одном решении. Инструментарий также довольно зрелый (интеграция VS и инструмента командной строки для CI)

Ответ 2

Maven подталкивается проектами apache, которые являются основной частью огромной инфраструктуры Java с открытым исходным кодом. Широко распространенное принятие maven должно быть связано с этим, и текущий уровень зрелости (качество) также очень хорош.

Я не думаю, что мир с открытым исходным кодом .NET имеет значительных сторонников с открытым исходным кодом, чтобы продвигать такую ​​концепцию. Как-то .NET всегда, кажется, ждет редмонда для этих вещей.

Ответ 3

Хотя вопрос старый, вот мои мысли. Maven - это не просто инструмент построения, он намного больше, чем управление репозиториями, управление проектами, управление зависимостями, управление построением и т.д....

Но главной привлекательностью, на мой взгляд, является управление зависимостями. JAR hell - это большая проблема в Java Land с самого начала, и вам нужно немного инструментов, чтобы справиться с этим. В мире .Net нет такой проблемы (на самом деле отсутствие аддона DLL было объявлено в качестве основной привлекательности в первые дни .Net), поэтому большинство людей отлично справляются с MSBuild. Позже из-за наличия большого количества сторонних библиотек были проблемы с управлением. Чтобы избавиться от этой проблемы, у них теперь есть Nuget.

Итак, вкратце, MsBuild + Nuget достаточно хорош в мире .Net для большей части проекта, Maven просто перехитрил их.

Ответ 4

Я согласен с множеством ответов здесь. У .NET не было большого количества независимых IDE, вы использовали Visual Studio для написания кода, управления вашими зависимостями и т.д. Решение в VS достаточно хорошо для MSBuild, поэтому вы используете серверы сборки.

Java, с другой стороны, разработала множество IDE, и Java пошла по пути управления проектами, внешними из IDE. Освобождение разработчика от использования их IDE. Недавно я начал перекрестное обучение с С# на Java, и я могу сказать вам, что концепция построения maven довольно чужая, но потом через некоторое время мне это нравится, и что еще более важно, я вижу, что предлагает концепция репо.

Теперь, как VS управляемые зависимости требуют, чтобы вы добавляли ссылку на проект или ссылку на DLL. Это добавление ссылки на DLL является ошибочным. Как вы управляете изменением версий, как вы структурируете сторонние DLL файлы из внешних и внутренних источников, а также DLL, которые вы хотели бы включить из своей собственной команды, но не как ссылку на проект. Я сделал много обходов, основанных в основном на файловой структуре каталогов, но ни один из них не является элегантным или отличным, когда версии меняются. Также делает ветвление трудным, потому что это становится соображением в том, как вы структурируете каталоги.

Теперь я работал с Java и публичными репозиториями mavan, супер крутой. Я работал с Python, и pip install эффективно снова вытягивался из публичных репозиториев. Наконец, я снова сделал некоторые вещи на С# с VS 2015, и интеграция с Nuget - именно то, чего не хватало.

Теперь в корпоративной среде публичные репозитории не всегда доступны напрямую, поэтому вам нужны корпоративные репозитории. Опять-таки экосистемы, не входящие в систему Microsoft, впереди.

В основном суммирование Java развилось из более открытой исходной среды, где техническое обслуживание IDE не использовалось, тогда как .NET развилась из Visual Studio, управляющей проектом, и эти разные пути означали, что репо позже входит в Visual Studio.

Наконец, и это мое наблюдение, сообщество Java имеет тенденцию использовать другие рамки для людей больше, поскольку базовые библиотеки Java предлагают меньше. В то время как люди .NET пишут намного больше своего кода. Сообщество java имеет большую экосистему шаблонов и практик, тогда как .NET снова написала собственный код или ждала Microsoft. Это меняется, но снова показывает, почему .NET стоит за Java в требовании для репозиций.

Ответ 5

Мы используем NAnt, потому что нет реальной альтернативы, которая является такой же зрелой. Одновременно работая над несколькими проектами, мы работали над тем, чтобы иметь несколько версий библиотек и как с ними бороться. Предложение Maven действительно многообещающее, но недостаточно зрелое, чтобы быть полезным на платформе .NET.

Я думаю, что необходимость менее очевидна, так как большинство .NET-проектов используют Visual Studio, которая автоматически предлагает/внедряет структуру каталогов, зависимости и т.д. Это вводящее в заблуждение "решение", поскольку в зависимости от IDE для этих видов соглашений ограничена гибкость команды разработчиков и блокируется в конкретном решении и поставщике. Очевидно, что это не так в мире Java, поэтому явная потребность в инструменте Maven.

Ответ 6

Мы используем UppercuT. UppercuT использует NAnt для сборки, и это безумно прост в использовании Build Framework.

Автоматизированная сборка проста: имя решения (1), (2) путь управления исходным кодом, (3) название компании для большинства проектов!

https://github.com/chucknorris/uppercut/

Несколько хороших объяснений здесь: UppercuT

Дополнительная информация

UppercuT - обычная автоматическая сборка, что означает, что вы настроили файл конфигурации, а затем получаете кучу функций бесплатно. Вероятно, самой мощной функцией является возможность указывать настройки среды в ОДНОМ месте и применять их повсюду, включая документацию при ее создании.

Доступна документация: https://github.com/chucknorris/uppercut/wiki

Особенности:

• Простая настройка
• Простые обновления
• Пользовательские точки расширения (pre, post и replace) для каждого этапа процесса сборки http://uppercut.pbworks.com/CustomizeUsingExtensionPoints
• Имеет документацию для интеграции с Team City, CruiseControl.NET и Дженкинсом (ранее Хадсон) https://github.com/chucknorris/uppercut/tree/master/docs
• Работает на Linux с моно /
• Версии DLL на основе номера сборки и версий управления версиями (SVN, TFS, Git, HG)
• Скомпилировать действия - F5 или Ctrl + Shift + B
• Сильное именование, сделанное так же просто, как true/false
• Тестирование и анализ кода
  • Тестирование
    • NUnit
    • MbUnit v2
    • Gallio
    • XUnit
  • NCover
  • NDepend
  • Nitriq
  • Монографический анализатор
• Obfuscation
• ILMerge
• Окружающая среда Templating and Building (ConfigBuilder, DocBuilder, SQLBuilder, DeploymentBuilder) https://github.com/chucknorris/uppercut/blob/master/docs/ConfigBuilder.doc?raw=true
• Выходной файл для подготовки к развертыванию
• Замедляет выход

Ответ 7

Мне не нравятся инструменты сборки на основе XML.

Мы адаптировали рубиновый грабли для сборки наших продуктов .net. Albacore - действительно хороший набор задач rake для создания проектов .net.

Rake делает очень простым создание даже сложных скриптов сборки, и вы имеете дело с кодом вместо тонны угловых скобок.

Ответ 8

Я знаю, что это старый пост, но когда я столкнулся с ним, я хотел поделиться другой отличной альтернативой.

Build Automation with PowerShell and Psake  

Многие люди не используют Psake (произносится как sockey), действительно здорово, что он использует msbuild.

Хотя это не ответ на вопрос maven (maven вышло из-за необходимости создания java на основе утомительных подробных скриптов ANT).

Большинство людей не используют CI (непрерывная интеграция), например, Jenkins, Hudson, Cruise Control, TeamCity, TFS и не используют powershell.

Этот PSake для Powershell, который использует msbuild, делает вещи ориентированными на задачи и очень организованными. Вот пример ссылки http://www.shilony.net/2013/06/15/build-automation-with-powershell-and-psake/