.net maven-2 build-process build build-automation

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



maven-2 build-process (8)

Tengo la impresión de que en .NET-world, no hay una necesidad real de una herramienta parecida a Maven.

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

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

¿Mi percepción es correcta?

¿Por qué es este el caso?

¿Qué están usando realmente las personas en .NET? No hay una resolución de dependencia automática en absoluto?

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

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

¿Cuáles son tus experiencias?

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

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

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

Estamos usando NAnt porque no hay 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 proposición 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, lo que sugiere / impone automáticamente una estructura de directorio, dependencias, etcétera. Esta es una ''solución'' engañosa, ya que dependiendo de un IDE para este tipo de convenciones, limite la flexibilidad del equipo de desarrollo y lo bloquee en una solución y proveedor específicos. Este obviamente no es el caso en el mundo de Java, de ahí la clara necesidad de una herramienta como Maven.

Estoy de acuerdo con muchas de las respuestas aquí. .NET no tenía una gran cantidad de IDEs independientes, usted 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 de sus servidores de compilación.

Java, por otro lado, desarrolló muchos IDEs y Java realizó una ruta de administración de proyectos externos desde el IDE. Liberar al desarrollador para usar su IDE de elección. Recientemente comencé el entrenamiento cruzado de C # a Java y puedo decirles que el concepto de construcción de maven es bastante extraño, pero después de un tiempo me encanta y, más importante, veo lo que el concepto de repos me ofrece.

Ahora, cómo las dependencias administradas de 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 desde fuentes externas e internas, así como las dlls que desea incluir de su propio equipo, pero no como referencia de proyecto? He realizado muchas soluciones basadas en general en la estructura de directorios basada en archivos, pero ninguna de ellas es elegante, o excelente cuando cambian las versiones. También dificulta la bifurcación porque eso se vuelve una consideración en la forma en que se estructuran los directorios.

Ahora he trabajado con Java y public mavan repos, super cool. He trabajado con Python y pip install de manera efectiva, volviendo a instalar 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 repos públicos no siempre son accesibles directamente, por lo que necesita repositorios corporativos. De nuevo, los ecosistemas que no son de Microsoft están a la cabeza en esto.

Básicamente, resumir Java evolucionó a partir de un entorno de fuente más abierta donde no se utilizaba el mantenimiento del proyecto IDE mientras que .NET evolucionó a partir de Visual Studio administrando el proyecto, y estas diferentes rutas significaron que los repos aparecerían más adelante en Visual Studio.

Finalmente, y esta es mi observación, la comunidad Java tiende a utilizar los marcos de otras personas más, ya que las bibliotecas base de Java ofrecen menos. Mientras que las personas .NET escriben 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 escribió código propio o esperó a Microsoft. Esto está cambiando, pero nuevamente muestra por qué .NET está detrás de Java en el requisito de repos.

Maven está siendo empujado por los 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 de código abierto .NET tenga ningún actor de código abierto significativamente grande para impulsar ese concepto. De alguna manera .NET siempre parece esperar a Redmond por estas cosas.

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

Adaptamos el rastrillo de rubí para construir nuestros productos .net. Albacore es una muy buena suite de tareas de rake para construir 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.

Para la resolución de 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 verificar los artefactos de dependencia binaria en vcs. Vea estos artículos .

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

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

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

Build Automation with PowerShell and Psake

Mucha gente no se está aprovechando de Psake (sockey pronunciado), 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 Java basadas en las tediosas y detalladas secuencias de comandos ANT).

La mayoría de las personas no usa ningún CI (integración continua) como Jenkins, Hudson, Cruise Control, TeamCity, TFS y tampoco usa powershell.

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

Usamos UppercuT. UppercuT usa NAnt para construir y es el Framework de construcción terriblemente fácil de usar.

¡Las compilaciones automatizadas son tan sencillas como (1) nombre de la solución, (2) ruta de control de origen, (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 características de forma gratuita. Podría decirse que la característica más poderosa es la capacidad de especificar configuraciones de entorno en UN lugar y hacer que se apliquen en todas partes, incluida la documentación cuando crea la fuente.

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

Caracteristicas :

  • Configuración simple
  • Actualizaciones simples
  • Puntos de extensión personalizados (pre, post y replace) para cada paso del proceso de compilación http://uppercut.pbworks.com/CustomizeUsingExtensionPoints
  • Tiene documentación para integración con Team City, CruiseControl.NET y Jenkins (anteriormente Hudson) https://github.com/chucknorris/uppercut/tree/master/docs
  • Funciona en Linux con Mono
  • Versiones DLL basadas en el número de compilación y las revisiones de control de origen (SVN, TFS, Git, HG)
  • Actividades de compilación: F5 o Ctrl + Shift + B
  • Denominación fuerte hecha tan fácil como verdadera / falsa
  • Prueba y análisis de código
    • Pruebas
      • NUnit
      • MbUnit v2
      • Gallio
      • xUnit
    • NCover
    • NDepender
    • Nitriq
    • Mono Migration Analyzer
  • Ofuscación
  • ILMerge
  • Creación de plantillas y creación de entornos (ConfigBuilder, DocBuilder, SQLBuilder, DeploymentBuilder) https://github.com/chucknorris/uppercut/blob/master/docs/ConfigBuilder.doc?raw=true
  • Empaquetar salida para prepararse para la implementación
  • Descomprime la salida