Dlaczego nie ma potrzeby Maven in.NET?

Mam wrażenie, że w świecie. NET nie ma potrzeby używania narzędzia podobnego do Mavena.

Zdaję sobie sprawę, że istnieje Byldan i NMaven (czy jeszcze żyje?), ale nie widziałem jeszcze prawdziwego projektu, który z nich korzysta.

Również w większości projektów. NET, nad którymi pracowałem, nigdy nie było potrzeby użycia narzędzia podobnego do Mavena. Problemy, które rozwiązuje Maven maven (Automatyczne rozwiązywanie zależności, struktura budowania oparta na konwencjach ...) wydają się nie być tak ważne in. NET.

Czy moja percepcja jest prawidłowa?

Dlaczego tak jest?

Czego ludzie tak naprawdę używają w. NET? żadnego automatycznego rozwiązywania zależności?

Czy oni piszą własne narzędzia do budowania?

Czy ktoś używa Mavena do zarządzania projektami. NET? Czy to dobry wybór?

Jakie są wasze doświadczenia?

Author: jbandi, 2009-04-08
Source

8 answers

Dla rozwiązywania zależności artifact, powiedziałbym, że Nuget jest teraz preferowaną alternatywą. Obsługuje i promuje rozdzielczość czasu kompilacji, tzn. nie ma potrzeby sprawdzania binarnych artefaktów zależności w vcs. Zobacz Te Artykuły .

Od wersji 2.7 Nuget, rozdzielczość czasu kompilacji ma jeszcze lepsze wsparcie z poleceniem NuGet restore jako jedną z opcji.

Aktualizacja: Dostępny jest teraz alternatywny, kompatybilny z nuget menedżer pakietów - Paket to jest lepsze niż klient vanilla nuget w obsłudze przejściowych zależności i harmonizacji zależności między projektami w tym samym rozwiązaniu. Narzędzia wydają się być również dość dojrzałe (VS integracja i narzędzia wiersza poleceń dla CI)

 36
Author: 8DH,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-08-27 08:02:29

Maven jest wspierany przez projekty apache, które są podstawową częścią ogromnej java open source infrastructure. Powszechne przyjęcie Mavena musi być z tym związane, a obecny poziom dojrzałości (jakości) jest również bardzo dobry.

Myślę, że świat. NET open source nie ma żadnych znacząco dużych podmiotów open source, aby popchnąć taką koncepcję. Jakoś. NET zawsze wydaje się czekać na redmond na te rzeczy.

 22
Author: krosenvold,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-04-08 11:34:23

Chociaż pytanie jest stare oto moje myśli . Maven nie jest po prostu narzędziem do budowania, robi o wiele więcej, jak zarządzanie repozytorium, zarządzanie projektami, zarządzanie zależnościami, zarządzanie kompilacją i tak dalej...

Ale główną atrakcją moim zdaniem jest zarządzanie zależnościami. Jar hell jest dużym problemem w świecie Javy od samego początku i potrzebujesz trochę narzędzi, aby sobie z tym poradzić. W świecie. Net nie ma takiego problemu (faktycznie brak DLL hell był reklamowane jako główna atrakcja w początkowych dniach. Net), więc większość ludzi jest w porządku z MSBuild. Później z powodu dostępności wielu bibliotek stron trzecich pojawiły się problemy z zarządzaniem. Aby pozbyć się tego problemu, mają teraz Nuget.

Tak W skrócie, MsBuild + Nuget jest wystarczająco dobry w świecie. Net dla większości projektu, Maven jest dla nich tylko przesadą.

 16
Author: Tinku,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-06-03 11:31:38

Zgadzam się z wieloma odpowiedziami tutaj. . NET nie miał dużej liczby niezależnych Idów, użyłeś Visual Studio do napisania kodu, zarządzania zależnościami itp. Rozwiązanie W VS jest wystarczająco dobre dla MSBuild, więc tego używasz z serwerów kompilacji.

Java z drugiej strony wyewoluowała wiele IDE i Java przeszła drogę zarządzania projektami zewnętrznymi z IDE. Uwolnienie dewelopera do korzystania z wybranego przez siebie IDE. Niedawno rozpocząłem cross training z C# do Java i mogę powiedzieć, że koncepcja budowania Mavena jest dość obca, ale po pewnym czasie ją uwielbiam, a co ważniejsze widzę, co oferuje mi koncepcja repo.

Teraz jak vs managed dependencies wymaga dodania odniesienia do projektu lub odniesienia do biblioteki DLL. To dodanie referencji DLL jest wadliwe. Jak zarządzasz zmianą wersji, jak strukturyzujesz biblioteki DLL innych firm z zewnętrznych i wewnętrznych źródeł, a także biblioteki DLL, które chcesz włączyć z własnego zespołu, ale nie jako odniesienie do projektu. Wykonałem wiele prac w oparciu o strukturę katalogów opartą na plikach, ale żaden z nich nie jest elegancki, ani świetny w przypadku zmian wersji. Utrudnia również rozgałęzianie, ponieważ staje się to brane pod uwagę w sposobie struktury katalogów.

Teraz pracowałem z Java i public mavan repos, super fajne. Pracowałem z Pythonem i pip install skutecznie ponownie ściągając z publicznych repozytoriów. W końcu zrobiłem kilka rzeczy w C # ponownie Z VS 2015 i integracja z Nuget jest dokładnie tym, czego brakowało.

Teraz w środowisku korporacyjnym publiczne transakcje repo nie zawsze są bezpośrednio dostępne, więc potrzebujesz korporacyjnych transakcji repo. Ponownie ekosystemy non Microsoft są do przodu w tej sprawie.

Podsumowując, Java ewoluowała ze środowiska open source, w którym obsługa projektu IDE nie była używana, podczas gdy. NET ewoluowała z Visual Studio zarządzającego projektem, a te różne ścieżki oznaczały, że repo ' s pojawią się później w Visual Studio.

Wreszcie i to jest moje spostrzeżenie, społeczność Java ma tendencję do korzystania z innych frameworków bardziej, ponieważ biblioteki Java base oferują mniej. Natomiast ludzie. NET piszą o wiele więcej własnego kodu. Społeczność java ma większy ekosystem wzorców i praktyk, podczas gdy. NET ponownie napisał własny kod lub czekał na Microsoft. To się zmienia, ale ponownie pokazuje, dlaczego. NET jest za Java w wymogu repos.

 12
Author: Mark Channing,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-04-15 02:45:06

Używamy NAnt, ponieważ nie ma prawdziwej alternatywy, która byłaby tak Dojrzała. Pracując nad wieloma projektami w tym samym czasie, pracowaliśmy nad posiadaniem wielu wersji bibliotek i sposobem radzenia sobie z nimi. Propozycja Mavena jest naprawdę obiecująca, ale nie na tyle dojrzała, aby była przydatna na platformie. NET.

Myślę, że potrzeba jest mniej oczywista, ponieważ większość projektów. NET używa Visual Studio, które automatycznie sugeruje / wymusza strukturę katalogów, zależności itp. To jest mylące "rozwiązanie", ponieważ w zależności od IDE dla tego rodzaju konwencji ogranicza elastyczność zespołu programistów i blokuje konkretne rozwiązanie i dostawcę. Oczywiście nie ma to miejsca w świecie Javy, stąd wyraźna potrzeba narzędzia podobnego do Mavena.

 5
Author: Kamiel Wanrooij,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-04-08 11:24:32

Nie lubię narzędzi do budowania opartych na XML.

Zaadaptowaliśmy Ruby rake do tworzenia naszych produktów. NET. [[3]}Albacore jest naprawdę ładnym zestawem zadań rake do budowania projektów. NET.

Rake sprawia, że tworzenie nawet złożonych skryptów budowlanych jest naprawdę łatwe i masz do czynienia z kodem zamiast ton nawiasów kątowych.

 2
Author: Zebi,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-06-13 19:11:47

Wiem, że to stary post, ale kiedy na niego natknąłem się, chciałem podzielić się inną świetną alternatywą. 

Build Automation with PowerShell and Psake

Wiele osób nie korzysta z Psake (wymawiane sockey) naprawdę fajną rzeczą jest to, że używa msbuild.

Chociaż nie jest to odpowiedź na pytanie Mavena (maven powstał z potrzeby tworzenia Javy opartej na żmudnych skryptach Ant).

Większość ludzi nie używa CI (continuous integration) jak Jenkins, Hudson, Cruise Control, TeamCity, TFS i nie używając powershell albo.

Ten PSake dla Powershell, który wykorzystuje msbuild, sprawia, że rzeczy są oparte na zadaniach i bardzo zorganizowane. Oto przykład linku http://www.shilony.net/2013/06/15/build-automation-with-powershell-and-psake/

 2
Author: Tom Stickel,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-10-28 08:04:03

Używamy UppercuT. UppercuT używa NAnt do budowania i jest szalenie łatwy w użyciu Build Framework.

Automatyczne tworzenie jest tak proste, jak (1) Nazwa rozwiązania, (2) ścieżka kontroli źródła, (3) Nazwa firmy dla większości projektów!

Https://github.com/chucknorris/uppercut/

Kilka dobrych wyjaśnień tutaj:

Więcej informacji

UppercuT jest konwencjonalną zautomatyzowaną kompilacją, co oznacza, że skonfigurujesz plik konfiguracyjny, a następnie otrzymasz kilka funkcji za darmo. Prawdopodobnie najpotężniejszą funkcją jest możliwość określania ustawień środowiska w jednym miejscu i stosowania ich wszędzie, w tym dokumentacji podczas kompilacji źródła.

Dostępna dokumentacja: https://github.com/chucknorris/uppercut/wiki

Funkcje:

 2
Author: ferventcoder,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-08-02 11:57:28