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).

 

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

 

  1. 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.

 

  1. 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’….”

 

  1. 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:

 

 

 

 

  • .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.


Humberto Jaimes
Humberto Jaimes

Me gusta ayudar a quienes están comenzando con el desarrollo móvil con Xamarin dando sesiones en línea, presenciales en universidades y también ayudo a las compañías que quieren capacitar a su equipo o en la creación de proyectos.

    8 replies to "¿Qué es .NET Standard?"

    • Bryan Oroxón

      Felicitaciones Humberto Jaimes, gran articulo bien explicado.

    • Miguel Muñoz

      Muy buen artículo Humberto 🙂

      El tema de la evolución del .NET Framework es un tanto confuso, la misma documentación de Microsoft me parece confusa también. Hay un párrafo en tu post que también lo comenta la documentación de Microsoft:

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

      ¿Cómo se debe entender?

      Que .NET Framework, Xamarin y .NET Core son implementaciones de .NET y por lo tanto ¿.NET es otro “algo” que tiene implementaciones?
      Eso a mí me confunde.

      Te dejo aquí un pequeño resumen sobre la relación entre .NET Framework, .NET Standard y .NET Core que utilizo para explicar ese tema. Nuevamente, un muy buen post el tuyo 🙂

      CLI
      El CLI (Common Language Infrastructure) define el ambiente virtual de ejecución de código que es independiente de cualquier plataforma,
      Common Language Infrastructure – la base formalizada de .NET – se estandarizó como ECMA 335 en 2001 y se aprobó como ISO / IEC 23271 en 2003.

      .NET Framework
      El .NET Framework es un entorno de ejecución administrado para Windows que proporciona una variedad de servicios para las aplicaciones en ejecución. El .NET Framework es la implementación Microsoft del CLI con funcionalidad adicional (por ejemplo, más APIs que las propuestas en el CLI).

      .NET Standard
      .NET Standard es una especificación formal de las API que se prevé que estén disponibles en todas las implementaciones del CLI. Entre las implementaciones del CLI se incluyen .NET Framework, .NET Core y Mono entre otras. La finalidad de .NET Standard es establecer una mayor uniformidad en el ecosistema de las distintas implementaciones del CLI. ECMA 335 sigue estableciendo uniformidad en el comportamiento de las implementaciones del CLI, pero no hay ninguna especificación parecida para las bibliotecas de clases base (BCL) que las implementaciones del CLI realizan.

      .NET Standard permite a los desarrolladores crear bibliotecas portables que se pueden usar en distintas implementaciones del CLI, utilizando este mismo conjunto de API.

      .NET Core
      .NET Core es una implementación modular, multiplataforma y de código abierto del .NET Standard diseñada para que sea portátil entre plataformas a fin de permitir la reutilización del código al máximo y su uso compartido. Contiene muchas de las mismas APIs que contiene el .NET Framework (pero .NET Core es un conjunto más pequeño)

      Saludos!

      • Humberto Jaimes

        Gracias Miguel, creo que esos conceptos pueden ayudar mucho a clarificar más lo expuesto en el post.

        A mi igual se me hizo complicado entender algunas cosas pero el que me ayudo mucho fue este glosario.

        Curiosamente ahi dice que las implementaciones de .NET son las que incluyen esto:
        – Uno o mas runtimes: CLR, CoreCLR, CoreRT.
        – Una librería de clases que implemente .NET Standard (que de acuerdo a lo que nos compartes implica que podría ser también una implementación de CLI)
        – Opcional algunos frameworks: ASP.NET, Windows Forms, and WPF
        – Opcional algunas herramientas de desarrollo

        Y otro detalle llamativo es que dice que el término .NET engloba a .NET Standard y a las implementaciones de .NET, entonces yo entiendo que .NET no sería otro «algo» mas bien todo lo que cumpla con esas «reglas» se puede llamar .NET de acuerdo a Microsoft.

        De esos conceptos que nos compartes creo que vale la pena agregar Mono ya que mucha de la gente que verá este post trabaja con Xamarin

        Mono:
        Mono es una implementación de .NET que se usa principalmente cuando se requiere un entorno de ejecución pequeño. Es el entorno de ejecución que activa las aplicaciones de Xamarin en Android, Mac, iOS, tvOS y watchOS, y se centra principalmente en aplicaciones que requieren una superficie pequeña. Admite todas las versiones de .NET Standard.

    • Miguel Muñoz

      Humberto, Perdon por cambiarte de nombre, el corrector ortográfico me jugó una mala pasada. 🙁

      • Humberto Jaimes

        No hay problema, ya lo cambié

    • rekiem

      excelente

    • Luis j. Sencion

      Excelente, gracias por la explicación.

    • adolfo vanegas

      Muchas gracias pro esta nota, quizás me pierdo un poco entre tantos conceptos que son nuevos para mi, pero según lo que leí, tu recomiendas que de aquí en adelante, se use .NET Estándar? . Saludos y gracias.

Leave a Reply

Your email address will not be published.