¿Qué es .NET Standard?

Hace unas semanas estaba actualizando mi curso “Xamarin Inteligente” con el tema de .NET Standard.

Debido a eso tuve que investigar para entender lo mas que se pudiera sobre este nuevo concepto y que no se quedará en que “son la evolución de las PCL y Visual Studio en PC ya te obliga a usarlas”.

Entonces compartiré un poco de lo que aprendí y al final dejaré el enlace a los vídeos en inglés de donde saque la mayoría de la información. Este es solo un resumen entonces si quieres ir mas a fondo y entiendes inglés puedes ir directo a esos vídeos.

Si quieres ver como migrar un proyecto PCL visita el siguiente post

¿Cómo funcionaba todo en un esquema sin .NET Standard?

Cuando creamos software usando .NET Framework, .NET Core o Xamarin estamos trabajando sobre Frameworks que incluyen un conjunto de tecnologías que trabajan sobre una misma base.

Por ejemplo WPF o ASP .NET tienen como base la .NET Framework Class Library;   ASP .NET Core trabaja sobre la CoreFX Class Library y Xamarin.Android y Xamarin.IOS trabajan sobre la Mono Class Library.

Estas bases pueden ser muy parecidas, pero al final son bibliotecas de clases diferentes, esto quiere decir, aunque estemos trabajando con C# y el mismo código de Xamarin funcione en una app de WPF y una de ASP .NET Core puede haber elementos que no funcionen igual en todos lados.

En el tiempo que llevo programando con Xamarin, por ejemplo, encontré diferencias en el cifrado AES cuando tenía un código como este:

using(AesCryptoServiceProvider aesProvider = new AesCryptoServiceProvider())
{
setAesProviderSettings(aesProvider);
result = aesProvider.CreateEncryptor().TransformFinalBlock(plainBytes,0, plainBytes.Length);
}

Usando File Linking (en aquellos tiempos en que las PCL y los SharedProject no existían para Xamarin), eso funcionaba en WPF, en Xamarin.Android pero en Xamarin iOS daba un error. No entrare en detalles del error, pero la solución era poner el código así

using(var aesProvider = Aes.Create())
{
setAesProviderSettings(aesProvider);
result = aesProvider.CreateEncryptor().TransformFinalBlock(plainBytes,0, plainBytes.Length);
}

Y el resumen de esta solución era que el usar el método Factory de AES en Xamarin.IOS por dentro hacia uso de la biblioteca CommonCrypto de Apple, lo cual al final es algo que por supuesto no usa WPF.

Y eso me pareció muy interesante, como el solo cambiar una línea hacia mas portable mi código.

En aquellos tiempos yo tendría menos de medio año de experiencia con Xamarin y como muchos había escuchado que existía un CLR, una BCL, Frameworks, tecnologías y una cantidad de conceptos sobre los que esta basado .NET pero que en realidad nunca había analizado como en ese momento en que entendí que Xamarin trabajaba sobre algo parecido, pero diferente como es Mono.

Ahora que salió ese concepto de .NET Standard y hace un tiempo cuando salió .NET Core los programadores .NET tuvieron/tienen que volver a repasar con esas diferencias para comprender como es que se logra esa portabilidad de código entre diferentes plataformas.

De forma gráfica es algo como esto.

¿Qué es una PCL (Portable Class Library)?

Si eres programador Xamarin seguro conoces este concepto, pero igual repasemos un poco.

En Xamarin existen varias formas de compartir el código File Linking, Shared Projects, PCLs y .NET Standard.

Hasta antes de que Visual Studio en PC pusiera .NET Standard y Shared Projects de forma predeterminada al crear un proyecto la opción era PCL y Shared Projects.

Y me parece que las PCL son el enfoque mas usado actualmente (en lo que se migra a .NET Standard), donde básicamente nosotros creamos una librería de clases que nos asegura ser compatible con todas las plataformas que fueran seleccionadas.

Para seleccionar esas plataformas se usa un Profile, que es un número que identifica al conjunto de plataformas compatibles, aquí algunos ejemplos

Aquí todos los profile https://portablelibraryprofiles.stephencleary.com

Entonces dependiendo del Profile se hacia una intersección de las APIs que eran comunes para cada plataforma y eso era lo que podíamos usar en nuestra PCL.

Entonces a mayor número de plataformas compatibles el número de APIs es menor. De forma gráfica sería algo así

Aquí había una serie de problemas, de inicio el Profile no indicaba demasiado, es decir no hay relación entre un Profile 111 y un Profile 259 y el número 259 no es mejor o mas nuevo que el 111 solo por tener un número mayor.

Otro problema es que es difícil o imposible saber que APIs podemos usar en la PCL.

Por ejemplo, si quieres consumir un servicio SOAP en una PCL, una solución es usar un Profile 78.  Pero volviendo a lo mencionado anteriormente el 78 no indica porque soluciona eso y si uno entra a ver las plataformas del Profile 78 son estas “portable-net45+win8+wp8”.

Entonces a futuro eso puede afectar en varias cosas de inicio el que soporte Windows Phone 8 va a reducir el número de APIs que se pueden utilizar y eso puede impactar en la compatibilidad de paquetes NuGet que se quieren instalar.

Y el problema de fondo es que alguna de las plataformas compatibles en nuestro Profile (111 o 259 probablemente) no soportaba algo que se requiere para los proxy que se usan para consumir SOAP.

Otro problema es que nuestra PCL compilada esta amarrada a esas plataformas, es decir que si mañana sale un .NET ABC PLUS que esta basado en otras clases base (no .NET, no CoreFX, no Mono).

1. Nosotros tendríamos que ir a buscar el Profile compatible con esa nueva implementación y con todas nuestras plataformas ya soportadas; con suerte nuestro código es compatible y todo se reduce a compilar de nuevo y darle esa nueva dll a cualquier persona que haga uso de ella.
2. Si son personas externas a nuestra empresa o son muchos proyectos los que dependen de esa dll puede ser un caos distribuír esa nueva PCL, sobre todo si hubo cambios de código para hacerla compatible con el nuevo Profile. Probablemente por eso no usamos uno de esos Shared Project “malignos”.

¿Qué es .NET Standard?

Ya con los antecedentes de cómo funcionan las cosas en .NET, Xamarin y .NET Core y que son las PCL ahora si hablemos de .NET Standard.

.NET Standard se puede ver como una evolución de las PCL que como su nombre lo indica ayudan a estandarizar las cosas.

¿Y como lo estandarizan? Principalmente en estos aspectos:

1. De inicio una biblioteca .NET Standard es una especificación de APIs, es decir es súper fácil saber si un API es compatible con .NET Standard y en que versión (https://apisof.net).

2. Todas las implementaciones de .NET (.NET Framework, Xamarin, .NET Core) pueden tener una misma base sobre la cual trabajar.

3. Las versiones de .NET Standard si indican mejoras, es decir la versión 2.0 es mejor que la 1.0. y mejor aún la versión 2.0 soporta todo lo de sus antecesores.

4. Como es una especificación, las plataformas implementan cierta versión esto quiere decir que, si sale ese .NET ABC PLUS, si este implementa .NET Standard 2.0 y nuestra biblioteca implementa 2.0 o anterior ese nuevo proyecto puede usar nuestro assembly sin ningún cambio.  Adios Profiles y errores “You are trying to install this package into aproject that targets ‘portable-net45+win+wp80+Xamarin.iOS10+MonoAndroid10+MonoTouch10’….”

5. Además, es Open Source y ver toda la documentación (plataformas, versiones, apis) y código en https://github.com/dotnet/standard/

Algunos puntos extra a tomar en cuenta:

• Para elegir la versión que debemos usar hay dos aspectos a tomar en cuenta
  • A mayor versión menos plataformas compatibles
  • A menor versión menos APIs disponibles

• Una versión mayor incluye todas las APIs de sus antecesores (Ya estaba arriba pero es importante)

• Existen Profiles de PCL compatibles con alguna versión de .NET Standard

• .NET Standard no es un Runtime es solo una especificación

• Las versiones son estáticas, es decir la versión 1 cuando se libera se mantiene con las APIs y plataformas con las que se libero, si se requiere que una de las APIs de esa versión sea soportada en una nueva plataforma se hace el cambio y se libera en una nueva versión, por ejemplo, la 1.1

Si quieres ver como migrar un proyecto PCL visita el siguiente post

Super recomendado

.NET Standard es súper interesante y extenso por lo que les recomiendo ver esta serie de vídeos, mucho de lo de este post lo aprendí de ahí y hay muchas cosas que me gustaría poner aquí, pero sería demasiado extenso para este post introductorio.