Pourquoi n’y a-t-il pas besoin de Maven dans .NET?

J’ai l’impression que dans le monde .NET, il n’y a pas vraiment besoin d’un outil de type Maven.

Je suis conscient qu’il y a Byldan et NMaven (est-ce qu’il est encore en vie?), Mais je n’ai pas encore vu de projet réel qui les utilise.

De plus, dans la plupart des projets .NET sur lesquels j’ai travaillé, le besoin d’un outil de type Maven n’a jamais été exprimé. Les problèmes auxquels Maven maven est confronté (résolution automatique des dépendances, structure de construction basée sur des conventions …) ne semblent pas si importants dans .NET.

Est-ce que ma perception est correcte?

pourquoi est-ce le cas?

Qu’est-ce que les gens utilisent vraiment dans .NET? Pas de résolution automatique des dépendances?

Est-ce qu’ils écrivent leurs propres outils de construction?

Est-ce que quelqu’un utilise Maven lui-même pour gérer ses projets .NET? Est-ce un bon choix?

Quelles sont vos expériences?

Pour la résolution des dépendances aux artefacts, je dirais que Nuget est désormais la solution préférée. Il prend en charge et favorise la résolution du temps de construction, c’est-à-dire qu’il n’est pas nécessaire de vérifier les artefacts de dépendance binary dans les vcs. Voir ces articles .

A partir de la version 2.7 de Nuget, la résolution du temps de construction est encore mieux supscope avec la commande Nuget restore parmi les options.

Mise à jour: Il existe maintenant un autre gestionnaire de paquets compatible avec nuget: Paket , mieux que le client nuget vanilla, pour gérer les dépendances transitoires et harmoniser les dépendances entre les projets dans la même solution. L’outillage semble également bien avancé (intégration de VS et outils en ligne de commande pour les CI)

Maven est poussé par des projets Apache, qui font partie intégrante de l’infrastructure Java open source. L’adoption généralisée de maven doit être liée à cela, et le niveau actuel de maturité (qualité) est également très bon.

Je ne pense pas que le monde open source de .NET ait des acteurs open source significatifs pour faire passer un tel concept. D’une manière ou d’une autre, .NET semble toujours attendre Redmond pour ces choses.

Bien que la question soit ancienne, voici mes pensées. Maven n’est pas simplement un outil de construction, il fait bien plus que cela, comme la gestion de référentiels, la gestion de projet, la gestion des dépendances, la gestion des builds, etc.

Mais la principale attraction à mon avis est la gestion de la dépendance. JAR hell est un gros problème dans Java Land dès le début et vous avez besoin d’outils pour y faire face. Dans le monde .Net, il n’ya pas de problème comme ça (en fait, l’absence de DLL a été considérée comme une attraction majeure dans les premiers jours de .Net), donc la plupart des gens vont bien avec MSBuild. Plus tard, en raison de la disponibilité de nombreuses bibliothèques tierces, des problèmes de gestion se sont posés. Pour se débarrasser de ce problème, ils ont maintenant Nuget.

Donc, en bref, MsBuild + Nuget est assez bon dans le monde .Net pour la plupart du projet, Maven est juste excessif pour eux.

Je suis d’accord avec beaucoup de réponses ici. .NET ne possédait pas un grand nombre d’EDI indépendants, vous utilisiez Visual Studio pour écrire votre code, gérer vos dépendances, etc. La solution dans VS est suffisante pour MSBuild, c’est donc ce que vous utilisez à partir de vos serveurs de génération.

Java d’autre part a évolué de nombreux IDE et Java est passé par une voie de gestion de projets externes à l’EDI. Libérer le développeur pour utiliser son IDE de son choix. J’ai récemment commencé le cross training de C # en Java et je peux vous dire que le concept de construction de maven est très étrange, mais après un certain temps je l’adore et, plus important encore, je vois ce que le concept de repo me propose.

Maintenant, comment les dépendances gérées par VS nécessitent que vous ajoutiez une référence de projet ou une référence à une DLL. Cet ajout d’une référence DLL est erroné. Comment gérez-vous le changement de version, comment structurez-vous les fichiers tiers des sources externes et internes, ainsi que les fichiers que vous souhaitez inclure dans votre propre équipe, mais pas en tant que référence de projet? J’ai fait beaucoup de remèdes basés en général sur la structure de répertoires basée sur des fichiers, mais aucun n’est élégant, ou excellent lorsque les versions changent. Cela rend également difficile le twigment, car cela devient une considération dans la structure des répertoires.

Maintenant, j’ai travaillé avec Java et les mavan repos publics, super cool. J’ai travaillé avec Python et l’installation de pip avec succès à nouveau en tirant parti des repos publics. Enfin, j’ai fait quelques trucs en C # avec VS 2015 et l’intégration avec Nuget est exactement ce qui manquait.

Maintenant, dans les entresockets, les pensions ne sont pas toujours directement accessibles, vous avez donc besoin de mises en pension d’entresockets. Là encore, les écosystèmes non Microsoft sont en avance sur ce point.

En résumé, Java a évolué à partir d’un environnement plus open source où la maintenance du projet IDE n’a pas été utilisée, tandis que .NET a évolué à partir de Visual Studio gérant le projet, et ces différents chemins ont été intégrés à Visual Studio.

Enfin, et ceci est mon observation, la communauté Java a tendance à utiliser davantage les frameworks d’autres personnes car les bibliothèques de base Java offrent moins. Alors que les gens .NET écrivent beaucoup plus de leur propre code. La communauté java a un plus grand écosystème de modèles et de pratiques, tandis que .NET a de nouveau écrit son propre code ou attendu Microsoft. Ceci est en train de changer mais montre encore une fois pourquoi .NET est derrière Java dans l’exigence de mise en pension.

Nous utilisons NAnt car il n’y a pas de réelle alternative aussi mature. Travaillant sur plusieurs projets en même temps, nous avons travaillé avec plusieurs versions de bibliothèques et comment les gérer. La proposition Maven est vraiment prometteuse, mais pas assez mature pour être utile sur la plate-forme .NET.

Je pense que le besoin est moins évident puisque la plupart des projets .NET utilisent Visual Studio, qui suggère / applique automatiquement une structure de répertoires, des dépendances, etc. C’est une «solution» trompeuse, car dépendre d’un IDE pour ce type de conventions limite la flexibilité de l’équipe de développement et vous enferme dans une solution et un fournisseur spécifiques. Ce n’est évidemment pas le cas dans le monde Java, d’où le besoin évident d’un outil de type Maven.

Je n’aime pas les outils de construction basés sur XML.

Nous avons adapté le râteau à rbuy pour construire nos produits .net. Albacore est une très belle suite de tâches de rake pour construire des projets .net.

Rake rend très facile la création de scripts de construction même complexes et vous avez affaire à du code plutôt qu’à des tonnes de crochets.

Je sais que c’est un ancien message mais quand je l’ai rencontré, je voulais partager d’autres alternatives.

Build Automation with PowerShell and Psake 

Beaucoup de gens ne profitent pas de Psake (le sockey prononcé), le plus intéressant est d’utiliser msbuild.

Bien que ce ne soit pas une réponse à la question maven (maven est né d’un besoin de builds Java basé sur les scripts ANT fastidieux fastidieux).

La plupart des gens n’utilisent pas de CI (continuous integration) comme Jenkins, Hudson, Cruise Control, TeamCity, TFS et n’utilisent pas non plus powershell.

Ce jeu de rôle pour Powershell, qui exploite msbuild, permet de gérer les tâches de manière très organisée. Voici un exemple de lien http://www.shilony.net/2013/06/15/build-automation-with-powershell-and-psake/

Nous utilisons UppercuT. UppercuT utilise NAnt pour construire et il est incroyablement facile à utiliser Build Framework.

Automatisé Création aussi simple que (1) nom de la solution, (2) chemin de contrôle de la source, (3) nom de la société pour la plupart des projets!

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

Quelques bonnes explications ici: UppercuT

Plus d’information


UppercuT est une construction automatisée conventionnelle, ce qui signifie que vous configurez un fichier de configuration et que vous obtenez ensuite un tas de fonctionnalités gratuitement. La fonctionnalité la plus puissante est sans doute la possibilité de spécifier les parameters d’environnement dans un seul endroit et de les appliquer partout, y compris la documentation lorsqu’elle génère la source.

Documentation disponible: https://github.com/chucknorris/uppercut/wiki

Caractéristiques :

  • Configuration simple
  • Mise à niveau simple
  • Points d’extension personnalisés (pré, post et remplacement) pour chaque étape du processus de génération http://uppercut.pbworks.com/CustomizeUsingExtensionPoints
  • Possède une documentation pour l’intégration avec Team City, CruiseControl.NET et Jenkins (anciennement Hudson) https://github.com/chucknorris/uppercut/tree/master/docs
  • Fonctionne sous Linux avec Mono
  • Versions des versions basées sur le numéro de version et les révisions du contrôle de source (SVN, TFS, Git, HG)
  • Comstackr les activités – F5 ou Ctrl + Maj + B
  • Nom fort rendu aussi simple que vrai / faux
  • Test de code et parsing
    • Essai
      • NUnit
      • MbUnit v2
      • Gallio
      • xUnit
    • NCover
    • Dépendre
    • Nisortingq
    • Analyseur de migration mono
  • Obscurcissement
  • ILMerge
  • Environnement Templating and Building (ConfigBuilder, DocBuilder, SQLBuilder, DeploymentBuilder) https://github.com/chucknorris/uppercut/blob/master/docs/ConfigBuilder.doc?raw=true
  • Sortie de l’emballage pour préparer le déploiement
  • Zips jusqu’à la sortie