Почему в .NET нет необходимости в Maven? - PullRequest
71 голосов
/ 08 апреля 2009

У меня сложилось впечатление, что в мире .NET нет реальной необходимости в инструменте, подобном Maven.

Я знаю, что есть Byldan и NMaven (он все еще жив?), Но я еще не видел реального проекта, который бы их использовал.

Кроме того, в большинстве проектов .NET, над которыми я работал, никогда не было необходимости в инструменте, подобном Maven. Проблемы, которые решает Maven Maven (автоматическое разрешение зависимостей, структура сборки на основе соглашений ...), не так важны в .NET.

Правильно ли мое восприятие?

Почему это так?

Что люди действительно используют в .NET? Нет автоматического разрешения зависимостей вообще?

Они пишут свои собственные инструменты для сборки?

Кто-нибудь использует сам Maven для управления своими .NET-проектами? Это хороший выбор?

Какой у вас опыт?

Ответы [ 8 ]

37 голосов
/ 11 марта 2011

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

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

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

23 голосов
/ 08 апреля 2009

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

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

16 голосов
/ 24 марта 2013

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

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

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

14 голосов
/ 15 апреля 2016

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

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

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

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

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

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

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

5 голосов
/ 08 апреля 2009

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

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

2 голосов
/ 28 октября 2013

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

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/

2 голосов
/ 13 июня 2011

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

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

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

2 голосов
/ 16 мая 2009

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

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

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

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

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


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

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

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

  • Простая настройка
  • Простые обновления
  • Пользовательские точки расширения (предварительно, после и для замены) для каждого шага процесса сборки http://uppercut.pbworks.com/CustomizeUsingExtensionPoints
  • Имеется документация для интеграции с Team City, CruiseControl.NET и Jenkins (ранее Hudson) https://github.com/chucknorris/uppercut/tree/master/docs
  • Работает в Linux с Mono
  • Версионные библиотеки DLL на основе номера сборки и версий контроля версий (SVN, TFS, Git, HG)
  • Компиляция действий - F5 или Ctrl + Shift + B
  • Сильное наименование сделано так же просто, как истина / ложь
  • Тестирование и анализ кода
    • Тестирование
      • NUnit
      • MbUnit v2
      • Gallio
      • XUnit
    • NCover
    • NDepend
    • Nitriq
    • Mono Migration Analyzer
  • запутывание
  • ILMerge
  • Шаблонирование и построение среды (ConfigBuilder, DocBuilder, SQLBuilder, DeploymentBuilder) https://github.com/chucknorris/uppercut/blob/master/docs/ConfigBuilder.doc?raw=true
  • Вывод упаковки для подготовки к развертыванию
  • Zips up output
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...