Creando un servidor NuGet propio para distribuir nuestras librerías

Algo que nos puede pasar de forma habitual cuando llevamos un tiempo desarrollando aplicaciones es que tenemos nuestras propias librerías para solucionar problemáticas comunes que se repiten de forma periódica. Básicamente lo que tendremos como resultados son DLLs que estaremos exportando de las librerías y referenciándolas desde los proyectos que las necesiten.

Por supuesto que esto es muchísimo mejor que tener la lógica común duplicada en todas las aplicaciones, pero también tiene sus desventajas, las cuales estarán en mayor o menor medida dependiendo de las características de las librerías y la cantidad de aplicaciones que la usen.

La principal es la distribución manual que debemos hacer de ese archivo para todas las aplicaciones clientes que deban usarlo. Normalmente lo que hacemos es copiarla desde otro proyecto que ya la esté usando. Además hay más problemas, ya que al hacer esto vamos a estar subiendo al repositorio de control de código fuente este archivo binario lo cual no deberíamos hacer. Más problemas tendremos cuando nuestra librería evolucione y tenga distintas versiones: ¿cómo sabemos cuál es la que tiene cada aplicación, la que necesitamos nosotros, si hay una nueva versión disponible, las dependencias que tiene cada una de esas versiones?

Está claro que la solución de todo esto es conocida desde hace tiempo, que es tener un paquete Nuget que encapsule todo esto. Pero necesitamos un servidor que nos provea los paquetes y en determinados casos (sobre todo en entornos empresariales) no podemos subir las librerías que se desarrollen en el repositorio público nuget.org

¿Entonces que hacemos? Sencillo, creemos nuestro servidor Nuget propio.

Básicamente es un sitio ASP.NET corriendo en algún entorno al que podamos acceder (puede estar expuesto a internet, en una intranet o hasta en nuestro equipo) con algunas particularidades. Veamos cómo crearlo:

Leer más »

Anuncios

.NET Standard, una librería para dominarlos a todos

Como he comentado en uno de los posts anteriores, en una de las charlas que he dado en el #NetRaf2017 comenté el estado de la plataforma .NET en el 2017. Uno de los puntos interesantes para comentar en mayor detalle es el asociado a .NET Standard, una librería que llega para dominarlos a todos.

Estado actual

Al día de hoy tenemos 3 grandes pilares que conforman la plataforma .NET, cada uno con un propósito bien definido (y muy distinto del que tienen los demás pilares):

NetStandard - Pilares.png

Veamos cada uno en más detalle:

.NET Framework:

Es la alternativa que veníamos usando hasta el día de hoy en el desarrollo de nuestras aplicaciones, también conocida como Full Framework en la actualidad. Se distribuye con el sistema operativo (es lo que estamos acostumbrados hasta el día de hoy, para correr una aplicación .NET debíamos tener la versión correspondiente del Framework instalada en el equipo.

.NET Core:

Es la versión multiplataforma del Framework, más reducida y compacta. Tiene un énfasis muy fuerte en lo que es la optimización del rendimiento, además de dar muchas soluciones a los desarrolladores de forma nativa que antes requerían siempre instalar dependencias adicionales. Lo podemos ver como una versión aggiornada del Full Framework. Dentro de los cambios que introduce, el Framework se distribuye con la aplicación, por lo cual las aplicaciones que hagamos son 100% autocontenidas.

Xamarin:

Plataforma que nos permite hacer desarrollos que corran en gran parte de las aplicaciones móviles, basada en el runtime de Mono (más detalles en este post que escribí introduciendo a Xamarin). Al igual que con .NET Core, el Framework se distribuye con la aplicación, lo cual hace que estas aplicaciones tengan un tamaño final más alto que una equivalente hecha en Java para Android o en Swift para iOS.

Lo que pasa aquí es que cada una de estas plataformas tiene una forma diferente de implementación, particularmente en las API’s a bajo nivel que cada una implementa:

Leer más »

Habilitar restauración de paquetes NuGet

Generalmente cuando empezamos a trabajar con repositorios de código fuente, compartiendo las tareas con otras personas, nos encontramos con ciertos aspectos que debemos manejar de forma correcta. Uno de ellos es la configuración de paquetes NuGet.

Cuando creamos un proyecto, por defecto tendremos creada dentro de la carpeta de la solución una carpeta denominada packages. La misma contiene el contenido de todos los paquetes que se instalan por defecto, como EntityFramework o jQuery.

NugetRestore - Paquetes iniciales
Paquetes al crear un nuevo proyecto MVC

Leer más »