Чому в .NET немає потреби в Maven?

76

У мене складається враження, що у світі .NET немає реальної потреби в інструменті, подібному до Maven.

Я усвідомлюю, що існують Білдан та НМейвен (вони все ще живі?), Але я ще не бачив реального проекту, який би їх використовував.

Також у більшості проектів .NET, над якими я працював, ніколи не висловлювалася потреба у інструменті, подібному до Maven. Проблеми, які вирішує Maven maven (автоматичне вирішення залежностей, структура побудови на основі конвенцій ...), здається, не так важливі в .NET.

Чи моє сприйняття правильне?

Чому це так?

Що люди насправді використовують у .NET? Немає автоматичного дозволу залежностей взагалі?

Вони пишуть власні інструменти побудови?

Хтось використовує саму Maven для управління своїми проектами .NET? Це хороший вибір?

Який ваш досвід?

.net  maven-2  build-process  build  build-automation 
— jbandi
джерело
Microsoft вивчає шлях Мейвена. Якщо ви перейдете до останньої версії ASP.net 5, ви знайдете подібні речі там. Замість багатослівного XML там використовується файл json для вказівки залежностей
— Bargitta
1
@Bargitta: project.json тепер знову застарілий: xoofx.com/blog/2016/05/11/goodbye-project-json
— Янус Троелсен,
1
@JanusTroelsen вони йдуть назад
— Баргітта

Відповіді:

42

Для вирішення залежності артефактів я б сказав, що Nuget зараз є найкращою альтернативою. Він підтримує та сприяє вирішенню часу побудови, тобто немає необхідності перевіряти артефакти двійкової залежності у vcs. Дивіться ці статті .

Починаючи з версії 2.7 Nuget, розробка дозволу часу має ще кращу підтримку, оскільки один із варіантів - команда відновлення Nuget.

Оновлення: Зараз доступний альтернативний, сумісний з nuget менеджер пакунків - Paket, який краще, ніж клієнт vanilla nuget, обробляє перехідні залежності та узгоджує залежності між проектами в одному і тому ж рішенні. Інструментарій, здається, також досить зрілий (інтеграція VS та інструменти командного рядка для CI)

— 8DH
джерело
3
Nuget - це шлях. Без сумніву.
— BlueM
25

Maven підштовхується проектами apache, які є основною частиною величезної інфраструктури Java з відкритим кодом. Масове поширення maven повинно бути пов’язане з цим, і нинішній рівень зрілості (якості) також дуже хороший.

Я не думаю, що у світі .NET з відкритим кодом є якісь суттєво великі актори з відкритим кодом, які б просунули таку концепцію. Якимсь чином .NET, здається, завжди чекає Редмонда на ці речі.

— кросенвольд
джерело
49
Це тому, що у світі MS, якщо ви створите власний інструмент, і це добре, швидше за все, MS через рік-два вийде з подібним, і люди перестануть використовувати ваш. (Як сказав Джоел Спольскі, "якщо вам вдасться написати щось, що злітає, ви можете виявити, що ви просто проводили дослідження ринку для Microsoft")
— Nate CK,
5
@ NateC-K, чи це не добре? такий жорстокий світ цей. Якщо мс не робить таких речей, є секта, яка скаржиться, що не робить, і коли мс насправді приймає належні значущі проекти і починає вкладати зусилля та ресурси, навіть тоді це висміюється, також це не те, що потрібно спільноті, належні інструменти охоплюючи ширшу аудиторію, завдяки цим екосистема розробників буде рости колективно
— Шріватса Харіш Венкатарамана
10
Якщо проект з відкритим кодом створив інструмент, який потрібен громаді, тоді ні, держава-член створює еквівалентний інструмент для його заміни - це не те, що потрібно. У гіршому - це дублювання зусиль, яке не має жодної видимої мети, крім як забезпечити, щоб державі-члену належало все. Більш доречним є те, що держава-член призначить деяких платних розробників брати участь у проекті з відкритим кодом. Однак з мого попереднього зауваження, схоже, MS доклала серйозних зусиль, щоб приємніше пограти з відкритим кодом, що я ціную. Я сподіваюся, що відносини будуть покращуватися і в найближчі роки.
— Nate CK
У 2016 році ситуація, безумовно, змінилася щодо очікування Redmond на ці речі (інструменти побудови). Тепер у нас є dotnet (ядро) на Linux, а Nexus 3 підтримує nuget. Цілий новий світ.
— Ніко де Вет
Я майже впевнений, що вони зазвичай не відновлюють проекти з відкритим кодом, а підтримують їх та вдосконалюють - подібно до Json.Net. Інший приклад
— Авалонія
23

Хоча питання старе, ось мої думки. Maven - це не просто інструмент збірки, він робить набагато більше, ніж управління сховищами, управління проектами, управління залежностями, управління збірками тощо ...

Але головна привабливість, на мій погляд, - це управління залежністю. Пекло JAR - це велика проблема в Java Land з самого початку, і вам потрібні певні інструменти, щоб впоратися з цим. У світі .Net такої проблеми немає (насправді відсутність пекла DLL рекламували як головну визначну пам'ятку в початкові дні існування .Net), тому більшість людей добре працюють з MSBuild. Пізніше через наявність великої кількості сторонніх бібліотек виникли проблеми з управлінням. Щоб позбутися цієї проблеми, тепер у них є Nuget.

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

— Тінку
джерело
Я цілком згоден. Оригінальні запитання датували до введення NuGet.
— jbandi
14

Я погоджуюсь з багатьма відповідями тут. .NET не мав великої кількості незалежних середовищ розробки, ви використовували Visual Studio для написання коду, управління залежностями і т. Д. Рішення у VS досить добре для MSBuild, тож саме цим ви користуєтесь на своїх серверах збірки.

З іншого боку, Java розвинула багато середовищ розробки, і Java пішла шляхом управління проектами, зовнішніми від IDE. Звільнення розробника використовувати їх IDE на вибір. Нещодавно я розпочав перехресний тренінг з C # на Java, і можу сказати вам, що концепція збірки maven досить чужа, але потім через деякий час мені це подобається, і що більш важливо, я бачу, що пропонує мені концепція репо.

Тепер, як VS-керовані залежності вимагають додати або посилання на проект, або посилання на DLL. Це додавання посилання DLL є помилковим. Як ви керуєте зміною версій, як структуруєте сторонні DLL-файли із зовнішніх та внутрішніх джерел, а також DLL-файли, які ви хотіли б включити від власної команди, але не як посилання на проект. Я провів багато робочих процедур, заснованих загалом на файловій структурі каталогів, але жодна з них не є елегантною чи чудовою при зміні версій. Також ускладнює розгалуження, оскільки це стає важливим фактором у структуруванні каталогів.

Зараз я працював з Java та публічними репозиторіями mavan, супер круто. Я працював з Python та pip install ефективно, знову використовуючи публічні репозиторії. Нарешті, я знову зробив щось у C # з VS 2015, і інтеграція з Nuget - саме те, чого не вистачало.

Зараз у корпоративному середовищі публічні репозиторії не завжди є безпосередньо доступними, тому вам потрібні корпоративні репо. Знову ж таки, екосистеми, що не належать Microsoft, випереджають це.

В основному підбиваючи підсумки, Java виникла із середовища з більш відкритим кодом, де не використовувалось підтримка проекту IDE, тоді як .NET розвинувся з Visual Studio, що керує проектом, і ці різні шляхи означали, що репо згодом з’являться у Visual Studio.

Нарешті, і це моє зауваження, спільнота Java, як правило, більше використовує фреймворки інших людей, оскільки базові бібліотеки Java пропонують менше. Тоді як люди .NET пишуть набагато більше власного коду. Спільнота Java має більшу екосистему шаблонів і практик, тоді як .NET знову писав власний код або чекав на Microsoft. Це змінюється, але знову показує, чому .NET відстає від Java у вимозі до репозиторіїв.

— Марк Ченнінг
джерело
1
Ви пробували Paket?
— Янус Трольсен
З ядром .net у нас сьогодні є IDE jetbrains rider. Я буду чекати більшого.
— Джон
6

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

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

— Каміель Ванрой
джерело
З іншого боку, ми перейшли з NAnt на MSBuild, оскільки ручне управління сценарієм NAnt - це величезний біль. VS робить це за вас. У мене є головний файл проекту MSBuild, написаний від руки в редакторі xml, який запускає модульні тести тощо і викликає інший файл msbuild (згенерований VS) лише для створення джерела.
— Іван Г.
Дивлячись на графік співавтора Github, здається, що NAnt застоювався. Ви все-таки рекомендуєте?
— Янус Трольсен
1
@JanusTroelsen Я вже кілька років не працюю в .NET. Я запитував, і найбільш чутною альтернативою є пакети NuGet з Paket або просто PowerShell.
— Kamiel Wanrooij
2

Мені не подобаються інструменти побудови на основі XML.

Ми адаптували граблі з рубіном для створення наших продуктів .net. Albacore - це справді приємний набір рейкових завдань для побудови проектів .net.

Rake дозволяє по-справжньому легко створювати навіть складні сценарії збірки, і ви маєте справу з кодом замість тонн кутових дужок.

— Зебі
джерело
Ви все ще використовуєте це? Я бачу, що Albacore все ще живе, нещодавно випущений v2.6.0.
— Янус Трольсен
2

Я знаю, що це стара публікація, але коли я натрапив на неї, я хотів поділитися іншою чудовою альтернативою. 

Build Automation with PowerShell and Psake

Багато людей не користуються перевагами Psake (яскраво виражений сокей), насправді круто в тому, що він використовує 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/

— Том Стікель
джерело
1
Мені дуже подобається psake для будівельних речей. Для управління залежностями я б дуже хотів можливість створювати файли package.config з рядка nuget.command. Приблизно так само, як це робиться, наприклад, у scriptcs.
— 8DH
Так, одного разу натрапивши на psake, я почав розповідати про це людям.
— Том Стікель,
Ви все-таки порекомендуєте Psake?
— Янус Трольсен
@JanusTroelsen Я не впевнений. Можливо, не так, як я просто не чув, щоб хтось говорив про це за останні 3 роки.
— Том Стікель,
"maven вийшов з-за потреби у збірках Java на основі нудних багатослівних сценаріїв ANT" ???
— Блаженний Гік
2

Ми використовуємо UppercuT. UppercuT використовує NAnt для побудови, і це шалено проста у використанні Build Framework.

Автоматизовані збірки такі ж прості, як (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 (раніше Хадсон) https://github.com/chucknorris/uppercut/tree/master/docs
  • Працює на Linux з Mono
  • Встановлення версій DLL на основі номера збірки та версій керування джерелом (SVN, TFS, Git, HG)
  • Компілювати дії - F5 або Ctrl + Shift + B
  • Сильне іменування стало таким же простим, як істинне / хибне
  • Тестування та аналіз коду
    • Тестування
      • NUnit
      • MbUnit v2
      • Галліо
      • xUnit
    • NCover
    • NDepend
    • Нітрик
    • Моноаналізатор міграції
  • Затуманення
  • ILMerge
  • Шаблонування та побудова середовища (ConfigBuilder, DocBuilder, SQLBuilder, DeploymentBuilder) https://github.com/chucknorris/uppercut/blob/master/docs/ConfigBuilder.doc?raw=true
  • Вихідні дані упаковки для підготовки до розгортання
  • Затискає на виході
— ferventcoder
джерело
Що робить це так легко? Чи є у нього якісь ключові точки продажу над іншими згаданими, щоб зробити використання цього більш привабливим?
— Дон Вінс,
Дерік Бейлі зробив огляд
— lostechies.com/derickbailey/2010/05/10/…
Це полегшує те, що це звичайна конструкція. Ви встановлюєте конфігурацію, а потім просто запускаєте build.bat. Коли до аперкоду додаються нові функції, ви можете оновити за лічені секунди.
— ferventcoder
1
Хадсон все ще поруч, Oracle "володіє" ним, але розробникам не сподобалось, як Oracle запускає речі, і, отже, вони створили ще одне ім'я дворецького під назвою Jenkins, і по суті Jenkins було добре сприйнято, і рівень його прийняття досить вражаючий.
— Tom Stickel
Я відредагував цю публікацію, щоб зазначити, що UppercuT було покинуто
— Янус Трольсен
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.