.net - OpenWrap vs NuGet

(3)

OpenWrap es un proyecto de código abierto que brinda administración de dependencias en aplicaciones, no solo en tiempo de compilación sino también en tiempo de ejecución.

Como tal, nuestras características se dirigen a la resolución dinámica de dependencias, ya sea para aplicaciones compuestas WPF, desarrollo de aplicaciones web o utilidades para todo el sistema. Esto hace que nuestra implementación sea muy diferente de lo que hace NuGet.

Así que aquí están las cosas que son diferentes (probablemente me olvidaré mucho, pero ah bien).

Sin dependencia de Visual Studio, y se centran en la productividad en la línea de comandos en lugar de en una interfaz de usuario
Sin dependencia de powershell, OW viene con su propio sistema de comando que le permite desarrollar, implementar y ejecutar sus propios comandos, ya sea desde nuestro shell (la herramienta o.exe) o desde MSBuild.
OpenWrap utiliza OpenWrap para compilarse e implementarse, y es compatible con xcopy en cada paso del camino.
Tiene un repositorio de paquetes en todo el sistema, por lo que puede implementar sus comandos de utilidad una vez en lugar de una vez por solución
Admite resolución de dependencia dinámica en tiempo de ejecución, si desea hacer eso
Tiene un formato de paquete extensible, por lo que puede crear nuevos tipos de dependencias en un paquete y hacer que OpenWrap lo ayude a usarlo en su aplicación
Compatible con paquetes OpenWrap y paquetes y repositorios NuGet
Se mantiene alejado de las complicaciones de XML y OData, y se basa en simples DSL basadas en texto que son fáciles y rápidas de aprender
Admite la compilación integrada para que puedas compilar y empaquetar tu solución de una sola vez
Admite repositorios personalizados en un recurso compartido de red que puede publicar desde el shell openwrap o las tareas msbuild
Proporciona nivelación de dependencia, seleccionando automáticamente qué combinación de versiones de paquetes se resuelve
La integración de Resharper significa que cualquier cambio que realice en sus dependencias se refleja en VS en tiempo real
La integración de TeamCity significa que puede compilar, empaquetar e implementar su paquete usando exactamente el mismo proceso, desde un script de MSBuild o desde la línea de comando.
Los constructores extensibles significa que puede cambiar cómo se desencadena la construcción dentro de OpenWrap
Soporte para corredores de prueba y pruebas de envío junto con paquetes
Utiliza los puntos de extensibilidad de MSBuild admitidos para incluir referencias de ensamblaje y deja el código que construyó solo. Una vez que envía los archivos binarios, no tiene dependencia de código de envoltura abierta , solo en tiempo de compilación.

Eso es solo por las diferencias, ya que eso es lo que preguntaste, así que no te molestaré con lo que hacemos igual que con otros gerentes de paquetes.

Cuál es la diferencia entre OpenWrap y NuGet. Y lo que prefieres?

Solo quería compartir algunas ideas del lado NuGet de las cosas. Seb omite algunos detalles que vale la pena señalar.

Si bien nuestra UI principal está basada en VS, el ensamblaje NuGet básico no tiene ningún vínculo con VS. El producto ASP.NET Web Pages tiene un administrador de paquetes basado en la web. Escribí una publicación de blog que muestra un ejemplo del uso de NuGet para construir un sitio web que se actualiza en tiempo de ejecución. http://haacked.com/archive/2011/01/15/building-a-self-updating-site-using-nuget.aspx
NuGet ofrece una poderosa consola PowerShell. Los paquetes NuGet pueden agregar nuevos comandos a la consola. Ver http://blog.stevensanderson.com/2011/01/13/scaffold-your-aspnet-mvc-3-project-with-the-mvcscaffolding-package/ . Como antes, este es un cliente de NuGet y el núcleo de NuGet no lo requiere.
NuGet está disponible para su instalación a través de la galería de extensiones VS y es muy fácil comenzar de inmediato.
NuGet admite señalar al cliente en un directorio (o recurso compartido de red) que contiene un conjunto de paquetes y lo trata automáticamente como un repositorio. Entonces, si no quieres tratar con OData, no tienes que hacerlo. Pero también incluimos una implementación de nuestra galería, por lo que no es necesario tratar manualmente con OData / XML en ningún caso.
NuGet no requiere que implemente ninguna parte de NuGet como parte de su aplicación. Se mantiene alejado de las manos y se centra en la automatización de los pasos que tomaría sin NuGet para adquirir e implementar sus dependencias. Para ser claros, como señala Seb, tampoco lo hace OpenWrap. Solo quería dejar en claro que NuGet no requiere esto también.

Uno de los principios clave de NuGet (y una diferencia importante con OpenWrap) es que no intenta cambiar la forma en que trabaja. En cambio, hace que sea mucho más fácil hacer las cosas que ya hace hoy.

Digamos, por ejemplo, que está intentando usar una biblioteca Foo, que depende de una biblioteca Bar. Hoy, tendrías que encontrar esas bibliotecas manualmente, copiarlas a tu máquina y agregar referencias a ellas. Luego, aparecerán versiones más nuevas y se realizarán movimientos similares para actualizarlos.

En tal escenario, tanto NuGet como OW harán que sea más fácil incluir esas referencias, pero la diferencia clave es que NuGet lo hace de una manera completamente no invasiva. es decir, obtendrá los binarios en su máquina y los referencia de la misma manera que si lo hubiera hecho manualmente. Después de que lo haya hecho, su archivo de proyecto es completamente ''normal'', sin ningún vínculo con NuGet en la compilación o en el tiempo de ejecución.

Lo que esto significa es que si obtiene algunas bibliotecas a través de NuGet y pone su proyecto en control de fuente, otro desarrollador podrá usar su proyecto sin necesidad de NuGet.

El enfoque OpenWrap también tiene sus ventajas, pero para seguir esa ruta, debe estar dispuesto a usar OpenWrap todo el camino, y no ser capaz de alejarse de él.

Hay muchas otras diferencias (como el soporte de VS rico en NuGet), pero esto es lo que veo como la diferencia más fundamental entre los dos.