¿Por qué no hay necesidad de Maven en .NET?


76

Tengo la impresión de que en el mundo .NET no existe una necesidad real de una herramienta similar a Maven.

Soy consciente de que existen Byldan y NMaven (¿todavía está vivo?), Pero todavía no he visto un proyecto del mundo real que los utilice.

Además, en la mayoría de los proyectos .NET en los que he trabajado, nunca se expresó la necesidad de una herramienta similar a Maven. Los problemas que Maven maven está abordando (resolución automática de dependencias, estructura de compilación basada en convenciones ...) parecen no ser tan importantes en .NET.

¿Es correcta mi percepción?

¿Por qué es este el caso?

¿Qué está usando realmente la gente en .NET? ¿Ninguna resolución automática de dependencias?

¿Están escribiendo sus propias herramientas de construcción?

¿Alguien está usando Maven para administrar sus proyectos .NET? ¿Es una buena elección?

Cuales son tus experiencias?


Microsoft está aprendiendo el camino de Maven. Si va a la última versión de ASP.net 5, encontrará cosas similares allí. En lugar de XML detallado, el archivo json se usa allí para especificar dependencias
Bargitta

1
@Bargitta: project.json ahora está obsoleto nuevamente: xoofx.com/blog/2016/05/11/goodbye-project-json
Janus Troelsen

1
@JanusTroelsen van al revés
Bargitta

Respuestas:


42

Para resolver la dependencia de artefactos, diría que Nuget es ahora la alternativa preferida. Admite y promueve la resolución del tiempo de compilación, es decir, no es necesario registrar los artefactos de dependencia binaria en vcs. Vea estos artículos .

A partir de la versión 2.7 de Nuget, la resolución del tiempo de compilación tiene un soporte aún mejor con el comando Restaurar de Nuget como una de las opciones.

Actualización: ahora hay un administrador de paquetes alternativo y compatible con nuget disponible: Paket que es mejor que el cliente vanilla nuget para manejar dependencias transitorias y armonizar dependencias entre proyectos en la misma solución. Las herramientas también parecen ser bastante maduras (integración de VS y herramientas de línea de comandos para CI)


3
Nuget es el camino a seguir. Sin duda.
BlueM

25

Maven está siendo impulsado por proyectos de Apache, que son una parte central de la enorme infraestructura de código abierto de Java. La adopción generalizada de maven debe estar relacionada con esto, y el nivel actual de madurez (calidad) también es muy bueno.

No creo que el mundo del código abierto .NET tenga actores de código abierto significativamente grandes para impulsar este concepto. De alguna manera .NET siempre parece esperar a Redmond para estas cosas.


49
Eso es porque en el mundo de la EM, si construyes tu propia herramienta y es buena, es probable que la EM tenga una como esta en un año o dos y la gente deje de usar la tuya. (Como dijo Joel Spolsky, "si logra escribir algo que despega, puede encontrar que simplemente estaba haciendo una investigación de mercado para Microsoft".)
Nate CK

5
@ NateC-K, ¿no es bueno? un mundo tan cruel este. Si ms no está haciendo tales cosas, hay una secta que se queja de que no lo está haciendo, y cuando ms realmente adopta proyectos significativos adecuados y comienza a poner esfuerzos y recursos, incluso entonces es ridiculizado, tampoco es eso lo que la comunidad necesita, herramientas adecuadas llegando a un público más amplio, con estas cosas, el ecosistema de desarrollo crecerá colectivamente
Srivathsa Harish Venkataramana

10
Si un proyecto de código abierto ha creado una herramienta que la comunidad necesitaba, entonces no, MS crear una herramienta equivalente para reemplazarla no es lo que se necesita. En el peor de los casos, se trata de una duplicación de esfuerzos que no tiene otro propósito aparente que garantizar que MS sea el propietario de todo. Lo más apropiado es que MS asigne algunos desarrolladores pagados para que contribuyan al proyecto de código abierto. Sin embargo, desde que hice mi comentario anterior, parece que MS ha hecho un gran esfuerzo para jugar mejor con la comunidad de código abierto, lo cual agradezco. Espero que esa relación continúe mejorando en los próximos años.
Nate CK

Las cosas ciertamente han cambiado en 2016 con respecto a la espera de Redmond para estas cosas (herramientas de compilación). Ahora tenemos dotnet (core) en Linux y Nexus 3 admite nuget. Todo un mundo nuevo.
Nico de Wet

Estoy bastante seguro de que no suelen reconstruir proyectos de código abierto, sino que los respaldan y mejoran, al igual que Json.Net. Avalonia es otro ejemplo
gilmishal

23

Aunque la pregunta es vieja aquí están mis pensamientos. Maven no es simplemente una herramienta de construcción, hace mucho más que eso, como administración de repositorios, administración de proyectos, administración de dependencias, administración de compilación, etc.

Pero el principal atractivo en mi opinión es la gestión de la dependencia. El infierno JAR es un gran problema en Java Land desde el principio y necesita algunas herramientas para enfrentarlo. En el mundo .Net no hay ningún problema como ese (en realidad, la ausencia del infierno de DLL se había anunciado como una atracción importante en los primeros días de .Net), por lo que la mayoría de la gente está bien con MSBuild. Más tarde, debido a la disponibilidad de muchas bibliotecas de terceros, hubo problemas de administración. Para deshacerse de este problema ahora tienen Nuget.

En resumen, MsBuild + Nuget es lo suficientemente bueno en el mundo .Net para la mayor parte del proyecto, Maven es simplemente exagerado para ellos.


Estoy completamente de acuerdo. La pregunta original data antes de que se introdujera NuGet.
jbandi

14

Estoy de acuerdo con muchas de las respuestas aquí. .NET no tenía una gran cantidad de IDE independientes, usó Visual Studio para escribir su código, administrar sus dependencias, etc. La solución en VS es lo suficientemente buena para MSBuild, así que eso es lo que usa desde sus servidores de compilación.

Java, por otro lado, desarrolló muchos IDE y Java siguió una ruta de gestión de proyectos externos al IDE. Liberar al desarrollador para que use su IDE de elección. Recientemente comencé el entrenamiento cruzado de C # a Java y puedo decirles que el concepto de compilación de Maven es bastante extraño, pero luego de un tiempo me encanta y, lo que es más importante, veo lo que me ofrece el concepto de repositorio.

Ahora, cómo las dependencias administradas por VS requieren que agregue una referencia de proyecto o una referencia a una DLL. Esta adición de una referencia de DLL es defectuosa. ¿Cómo gestiona el cambio de versiones, cómo estructura las dlls de terceros a partir de fuentes externas e internas, así como las dlls que le gustaría incluir de su propio equipo pero no como referencia del proyecto? He realizado muchas soluciones temporales basadas en general en la estructura de directorios basada en archivos, pero ninguna de ellas es elegante o excelente cuando las versiones cambian. También dificulta la ramificación porque se convierte en una consideración en la forma en que se estructuran los directorios.

Ahora he trabajado con Java y repositorios públicos de mavan, super cool. He trabajado con Python y pip install de manera efectiva nuevamente extrayendo de repositorios públicos. Finalmente hice algunas cosas en C # nuevamente con VS 2015 y la integración con Nuget es exactamente lo que faltaba.

Ahora, en el entorno corporativo, los repositorios públicos no siempre son directamente accesibles, por lo que necesita repos corporativos. Nuevamente, los ecosistemas que no son de Microsoft están por delante en esto.

Básicamente, en resumen, Java evolucionó a partir de un entorno de código más abierto donde no se utilizó el mantenimiento del proyecto IDE, mientras que .NET evolucionó a partir de Visual Studio que administra el proyecto, y estas diferentes rutas significaron que los repositorios vendrán más tarde en Visual Studio.

Finalmente, y esta es mi observación, la comunidad Java tiende a usar más los marcos de otras personas, ya que las bibliotecas base de Java ofrecen menos. Mientras que la gente .NET escribe mucho más de su propio código. La comunidad java tiene un ecosistema más grande de patrones y prácticas, mientras que .NET nuevamente escribió su propio código o esperó a Microsoft. Esto está cambiando, pero nuevamente muestra por qué .NET está detrás de Java en el requisito de repositorios.


1
¿Probaste Paket?
Janus Troelsen

Con .net core, hoy tenemos jetbrains rider IDE. Esperaré más.
Juan

6

Estamos usando NAnt porque no existe una alternativa real que sea tan madura. Trabajando en múltiples proyectos al mismo tiempo, hemos trabajado para tener múltiples versiones de bibliotecas y cómo manejarlas. La propuesta de Maven es realmente prometedora, pero no lo suficientemente madura como para ser útil en la plataforma .NET.

Creo que la necesidad es menos obvia ya que la mayoría de los proyectos .NET usan Visual Studio, que automáticamente sugiere / refuerza una estructura de directorio, dependencias, etc. Esta es una 'solución' engañosa, ya que depender de un IDE para este tipo de convenciones limita la flexibilidad del equipo de desarrollo y lo encierra en una solución y un proveedor específicos. Obviamente, este no es el caso en el mundo de Java, de ahí la clara necesidad de una herramienta similar a Maven.


Por otro lado, migramos de NAnt a MSBuild, porque administrar manualmente el script de NAnt es una gran molestia. VS lo hace por ti. Tengo un archivo de proyecto maestro MSBuild escrito a mano en el editor xml que lanza pruebas unitarias, etc. e invoca otro archivo msbuild (generado por VS) solo para compilar la fuente.
Ivan G.

Mirando el gráfico del colaborador de Github , parece que NAnt se ha estancado. ¿Aún lo recomendarías?
Janus Troelsen

1
@JanusTroelsen No he trabajado en .NET desde hace algunos años ... Pregunté y la alternativa más escuchada son los paquetes NuGet con Paket o simplemente PowerShell.
Kamiel Wanrooij

2

No me gustan las herramientas de construcción basadas en XML.

Adaptamos el rastrillo ruby ​​para construir nuestros productos .net. Albacore es un conjunto realmente agradable de tareas de rake para crear proyectos .net.

Rake hace que sea realmente fácil crear incluso scripts de construcción complejos y se trata de código en lugar de toneladas de corchetes angulares.


¿Sigues usando esto? Veo que Albacore todavía está vivo, con la v2.6.0 recién lanzada.
Janus Troelsen

2

Sé que esta es una publicación antigua, pero cuando la encontré, quería compartir otra gran alternativa.

Build Automation with PowerShell and Psake  

Mucha gente no está aprovechando Psake (pronunciado sockey), lo realmente genial es que está usando msbuild.

Si bien esta no es una respuesta a la pregunta de maven (maven surgió de la necesidad de compilaciones de Java basadas en los tediosos y detallados scripts ANT).

La mayoría de las personas no están usando CI (integración continua) como Jenkins, Hudson, Cruise Control, TeamCity, TFS y tampoco usan PowerShell.

Este PSake para Powershell que aprovecha msbuild hace que las cosas estén basadas en tareas y estén muy organizadas. Aquí hay un ejemplo de enlace http://www.shilony.net/2013/06/15/build-automation-with-powershell-and-psake/


1
Me gusta mucho el psake por construir cosas. Para administrar dependencias, realmente me gustaría tener la posibilidad de crear archivos packages.config desde la línea nuget.command. Casi de la misma manera que se hace en scriptcs, por ejemplo.
8DH

Sí, una vez que me encontré con psake comencé a contárselo a la gente.
Tom Stickel

¿Seguirías recomendando Psake?
Janus Troelsen

@JanusTroelsen No estoy seguro. Probablemente no, ya que no he escuchado a nadie hablar de eso en los últimos 3 años.
Tom Stickel

"maven surgió de la necesidad de compilaciones java basadas en los tediosos y detallados scripts ANT" ???
Blessed Geek

2

Usamos UppercuT. UppercuT usa NAnt para construir y es increíblemente fácil de usar Build Framework.

¡Compilaciones automatizadas tan fáciles como (1) nombre de la solución, (2) ruta de control de fuente, (3) nombre de la empresa para la mayoría de los proyectos!

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

Algunas buenas explicaciones aquí: UppercuT

Más información


UppercuT es una compilación automatizada convencional, lo que significa que configura un archivo de configuración y luego obtiene un montón de funciones de forma gratuita. Podría decirse que la característica más poderosa es la capacidad de especificar la configuración del entorno en UN solo lugar y aplicarla en todas partes, incluida la documentación cuando se crea la fuente.

Documentación disponible: https://github.com/chucknorris/uppercut/wiki

Caracteristicas :

  • Configuración sencilla
  • Actualizaciones simples
  • Puntos de extensión personalizados (pre, post y reemplazo) para cada paso del proceso de construcción http://uppercut.pbworks.com/CustomizeUsingExtensionPoints
  • Tiene documentación para la integración con Team City, CruiseControl.NET y Jenkins (anteriormente Hudson) https://github.com/chucknorris/uppercut/tree/master/docs
  • Funciona en Linux con Mono
  • Control de versiones de archivos DLL basados ​​en el número de compilación y las revisiones de control de fuente (SVN, TFS, Git, HG)
  • Compilar actividades: F5 o Ctrl + Shift + B
  • Nombrar con fuerza es tan fácil como verdadero / falso
  • Prueba y análisis de código
    • Pruebas
      • NUnit
      • MbUnit v2
      • Galión
      • xUnidad
    • NCover
    • NDepend
    • Nitriq
    • Analizador de migración mono
  • Ofuscación
  • ILMerge
  • Creación de plantillas y entornos de entorno (ConfigBuilder, DocBuilder, SQLBuilder, DeploymentBuilder) https://github.com/chucknorris/uppercut/blob/master/docs/ConfigBuilder.doc?raw=true
  • Empaquetar la salida para preparar la implementación
  • Cremalleras de salida

¿Qué lo hace tan fácil? ¿Tiene algún punto de venta clave sobre los otros mencionados para que su uso sea más atractivo?
Don Vince


Lo que lo hace fácil es que es una construcción convencional. Establece la configuración y luego simplemente ejecuta build.bat. Cuando se agregan nuevas funciones a uppercut, puede actualizar en segundos.
ferventcoder

1
Hudson todavía existe, Oracle "lo posee", pero a los desarrolladores no les gustó la forma en que Oracle estaba ejecutando las cosas y por lo tanto crearon otro nombre de mayordomo llamado Jenkins y esencialmente Jenkins ha sido bien recibido y su tasa de adopción es bastante impresionante.
Tom Stickel

Edité esta publicación para señalar que UppercuT fue abandonado
Janus Troelsen
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.