.NET Standard

  • Artículo

.NET Standard es una especificación formal de las API de .NET que están disponibles en varias implementaciones de .NET. La finalidad de .NET Standard ha sido establecer una mayor uniformidad en el ecosistema de .NET. .NET 5 y versiones posteriores adoptan un enfoque diferente para establecer la uniformidad que elimina la necesidad de .NET Standard en la mayoría de los escenarios. Sin embargo, si quiere compartir código entre .NET Framework y cualquier otra implementación de .NET, como .NET Core, la biblioteca debe tener como destino .NET Standard 2.0. No se publicará ninguna nueva versión de .NET Standard, pero .NET 5 y todas las versiones posteriores seguirán siendo compatibles con .NET Standard 2.1 y versiones anteriores.

Para obtener información sobre cómo elegir entre .NET 5+ y .NET Standard, consulte .NET 5+ y .NET Standard más adelante en este artículo.

Versiones de .NET Standard

.NET Standard tiene versiones. Cada nueva versión agrega más API. Cuando una biblioteca se compila con una versión determinada de .NET Standard, se puede ejecutar en cualquier implementación de .NET que implemente esa versión de .NET Standard (o en una superior).

Establecer como destino una versión superior de .NET Standard permite que una biblioteca use más API, pero implica que solo se puede usar en versiones más recientes de .NET. Establecer como destino una versión inferior reduce las API disponibles, pero significa que la biblioteca se puede ejecutar en más lugares.

Seleccione la versión de .NET Standard

.NET Standard 1.0 tiene 7949 de las 37 118 API disponibles.

Implementación de .NET Compatibilidad con versiones
.NET y .NET Core 1.0, 1.1, 2.0, 2.1, 2.2, 3.0, 3.1, 5.0, 6.0, 7.0, 8.0
.NET Framework 4.5, 4.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2, 4.8, 4.8.1
Mono 4.6, 5.4, 6.4
Xamarin.iOS 10.0, 10.14, 12.16
Xamarin.Mac 3.0, 3.8, 5.16
Xamarin.Android 7.0, 8.0, 10.0
Plataforma universal de Windows 8.0, 8.1, 10.0, 10.0.16299, TBD
Unity 2018.1

Para más información, consulte .NET Standard 1.0. Para ver una tabla interactiva, consulte Versiones de .NET Standard.

Versión de .NET Standard de destino

Se recomienda tener como destino .NET Standard 2.0, a menos que tenga que admitir una versión anterior. La mayoría de bibliotecas de uso general no deberían necesitar API fuera de .NET Standard 2.0. Todas las plataformas modernas admiten .NET Standard 2.0 y es la manera recomendada para admitir varias plataformas con un destino.

Si tiene que admitir .NET Standard 1.x, le recomendamos que también establezca .NET Standard 2.0 como destino. .NET Standard 1.x se distribuye como un conjunto pormenorizado de paquetes NuGet, que crea un gráfico de dependencias de paquete grande y da lugar a que los desarrolladores descarguen una gran cantidad de paquetes al compilar. Para más información, consulte Destinatarios multiplataforma y .NET 5 y .NET Standard más adelante en este artículo.

Reglas de control de versiones de .NET Standard

Hay dos reglas de control de versiones principales:

  • Adición: las versiones de .NET Standard son círculos lógicamente concéntricos: las versiones superiores incorporan todas las API de las versiones anteriores. No hay ningún cambio importante entre versiones.
  • Inmutable: Una vez publicadas, las versiones de .NET Standard se congelan.

No habrá nuevas versiones de .NET Standard después de la versión 2.1. Para más información, consulte .NET 5 y .NET Standard más adelante en este artículo.

Especificación

La especificación de .NET Standard es un conjunto estandarizado de API. La especificación se mantiene mediante implementadores de .NET, específicamente Microsoft (que incluye .NET Framework, .NET Core y Mono) y Unity.

Artefactos oficiales

La especificación oficial es un conjunto de archivos .cs que definen las API que forman parte del estándar. El directorio ref en el repositorio dotnet/standard (ahora archivado) define las API de .NET Standard.

El metapaquete NETStandard.Library (código fuente) describe el conjunto de bibliotecas que definen (en parte) una o varias versiones de .NET Standard.

Un componente determinado, como System.Runtime, describe lo siguiente:

  • Parte de .NET Standard (solo su ámbito).
  • Varias versiones de .NET Standard para ese ámbito.

Se proporcionan artefactos derivados para permitir una lectura más cómoda y habilitar ciertos escenarios de desarrollo (por ejemplo, el uso de un compilador).

Representación de paquetes

El principal vehículo de distribución de los ensamblados de referencia de .NET Standard son los paquetes NuGet. Las implementaciones se entregarán de diversas formas, adecuadas para cada implementación de .NET.

Los paquetes NuGet tienen como destino uno o varios marcos. Los paquetes de .NET Standard tienen como destino el marco ".NET Standard". Puede establecer como destino el marco de .NET Standard mediante el TFM compactonetstandard (por ejemplo, netstandard1.4). Las bibliotecas diseñadas para ejecutarse en varias implementaciones de .NET deben tener como destino este marco. Para obtener el conjunto más amplio de API, indique netstandard2.0 como destino, puesto que el número de API disponibles se ha doblado entre .NET Standard 1.6 y 2.0.

El metapaquete NETStandard.Library hace referencia al conjunto completo de paquetes NuGet que definen .NET Standard. La manera más común de establecer como destino netstandard consiste en hacer referencia a este metapaquete. Describe y proporciona acceso a las aproximadamente 40 bibliotecas de .NET y las API asociadas que definen .NET Standard. Puede hacer referencia a paquetes adicionales que tienen como destino netstandard para obtener acceso a otras API.

Control de versiones

La especificación no es única, sino que se trata de un conjunto de API con versiones lineales. La primera versión del estándar establece un conjunto básico de API. Las versiones posteriores agregan API y heredan las API definidas por las versiones anteriores. No se ha establecido ninguna disposición para quitar API del estándar.

.NET Standard no es específico de ninguna implementación de .NET, ni coincide con el sistema de control de versiones de ninguna de esas implementaciones.

Como se ha mencionado antes, no habrá nuevas versiones de .NET Standard después de la versión 2.1.

.NET Standard como destino

Puede compilar bibliotecas de .NET Standard mediante una combinación del marco netstandard y el metapaquete NETStandard.Library.

Modo de compatibilidad de .NET Framework

A partir de .NET Standard 2.0 se ha introducido el modo de compatibilidad de .NET Framework. Este modo de compatibilidad permite que los proyectos de .NET Standard hagan referencia a bibliotecas de .NET Framework como si estuviesen compiladas para .NET Standard. Las referencias a bibliotecas de .NET Framework no funcionan para todos los proyectos, por ejemplo, en bibliotecas que usan API de Windows Presentation Foundation (WPF).

Para obtener más información, consulte Modo de compatibilidad de .NET Framework.

Bibliotecas de .NET standard y Visual Studio

Para compilar bibliotecas de .NET Standard en Visual Studio, asegúrese de que tiene Visual Studio 2022, Visual Studio 2019o Visual Studio 2017 versión 15.3 o posterior instalada en Windows o Visual Studio para Mac, versión 7. 1 o posterior instalada en macOS.

Si solo necesita consumir bibliotecas de .NET Standard 2.0 en sus proyectos, también puede hacerlo en Visual Studio 2015. Sin embargo, necesitará tener el cliente 3.6 de NuGet o uno posterior instalado. Puede descargar el cliente de NuGet para Visual Studio 2015 desde la página de descargas de NuGet.

.NET 5+ y .NET Standard

.NET 5, .NET 6, .NET 7 y .NET 8 son productos únicos con un conjunto uniforme de funcionalidades y API que se pueden usar para aplicaciones de escritorio de Windows y aplicaciones de consola multiplataforma, servicios en la nube y sitios web. Los TFM de .NET 8, por ejemplo, reflejan esta amplia gama de escenarios:

  • net8.0

    Este TFM es para el código que se ejecuta en todas partes. Con algunas excepciones, solo incluye tecnologías que funcionan entre plataformas. Para el código de .NET 8, net8.0 reemplaza los TFM netcoreapp y netstandard.

  • net8.0-windows

    Este es un ejemplo de un TFM específico del sistema operativo que agrega funcionalidad específica del sistema operativo a todo a lo que net8.0 hace referencia.

Cuándo se debe establecer como destino net8.0 frente a netstandard

Para el código existente que tiene como destino netstandard, no es necesario cambiar el TFM a net8.0 o un TFM posterior. .NET 8 implementa .NET Standard 2.1 y versiones anteriores. La única razón para volver a establecer el destino de .NET Standard a .NET 8+ sería obtener acceso a más características en tiempo de ejecución, características de lenguaje o API. Por ejemplo, para usar C# 9, el destino debe ser .NET 5 o una versión posterior. Puede tener como destino .NET 8 y .NET Standard para obtener acceso a las características más recientes y seguir teniendo la biblioteca disponible para otras implementaciones de .NET.

Estas son algunas instrucciones para el código nuevo de .NET 5+:

  • Componentes de la aplicación

    Si usa bibliotecas para dividir una aplicación en varios componentes, se recomienda usar net8.0. Para simplificar, es mejor mantener todos los proyectos que componen la aplicación en la misma versión de .NET. Después, puede suponer las mismas características de BCL en todas partes.

  • Bibliotecas reutilizables

    Si va a compilar bibliotecas reutilizables que planea enviar en NuGet, tenga en cuenta el equilibrio entre el alcance y el conjunto de características disponibles. .NET Standard 2.0 es la última versión admitida por .NET Framework, por lo que ofrece un buen alcance con un conjunto de características bastante amplio. No se recomienda establecer .NET Standard 1.x como destino, ya que se limitaría el conjunto de características disponibles a cambio de un mínimo aumento del alcance.

    Si no necesita admitir .NET Framework, puede usar .NET Standard 2.1 o .NET 8. Se recomienda omitir .NET Standard 2.1 y pasar directamente a .NET 8. Las bibliotecas más utilizadas tendrán como destino tanto .NET Standard 2.0 como .NET 5 y versiones posteriores. La compatibilidad con .NET Standard 2.0 le proporciona el máximo alcance, mientras que la compatibilidad con .NET 5 garantiza el aprovechamiento de las características más recientes de la plataforma para los clientes que ya usan .NET 5+.

Problemas con .NET Standard

Estos son algunos problemas con .NET Standard que ayudan a explicar por qué .NET 5 y versiones posteriores son la mejor manera de compartir código entre plataformas y cargas de trabajo:

  • Lentitud para agregar API nuevas

    .NET Standard se creó como un conjunto de API que todas las implementaciones de .NET debían admitir, por lo que hubo un proceso de revisión de las propuestas para agregar API nuevas. El objetivo era normalizar solo las API que se pudieran implementar en todas las plataformas .NET, actuales y futuras. Como resultado, si faltaba una característica en una versión concreta, es posible que tuviera que esperar un par de años antes de que se agregara a una versión de Standard. Después, tendría que esperar incluso más a que la nueva versión de .NET Standard tuviera compatibilidad suficiente.

    Solución en .NET 5+: cuando se implementa una característica, ya está disponible para cada aplicación y biblioteca de .NET 5+, porque la base de código está compartida. Y como no hay ninguna diferencia entre la especificación de la API y su implementación, puede aprovechar las ventajas de las nuevas características mucho más rápido que con .NET Standard.

  • Complejidad del control de versiones

    La separación de la especificación de la API de sus implementaciones da lugar a una asignación compleja entre las versiones de especificación de la API y las de implementación. Esta complejidad es evidente en la tabla que se ha mostrado antes en este artículo y en las instrucciones sobre cómo interpretarla.

    Solución en .NET 5+ : no existe separación entre la especificación de una API de .NET 5+ y su implementación. El resultado es un esquema de TFM simplificado. Hay un prefijo de TFM para todas las cargas de trabajo: se usa net8.0 para bibliotecas, aplicaciones de consola y aplicaciones web. La única variante es un sufijo que especifica las API específicas de la plataforma para una plataforma concreta, como net8.0-windows. Gracias a esta convención de nomenclatura de TFM, puede saber con facilidad si una aplicación concreta puede usar una biblioteca determinada. No se necesita una tabla de números de versión equivalentes como la de .NET Standard.

  • Excepciones no admitidas por la plataforma en tiempo de ejecución

    .NET Standard expone API específicas de la plataforma. El código se podría compilar sin errores y parecer ser portable a cualquier plataforma aunque lo no sea. Cuando se ejecuta en una plataforma que no tiene una implementación de una API determinada, se obtienen errores en tiempo de ejecución.

    Solución en .NET 5+ : los SDK de .NET 5+ incluyen analizadores de código que están habilitados de forma predeterminada. El analizador de compatibilidad de plataformas detecta el uso involuntario de las API que no se admiten en las plataformas en las se que pretenden ejecutar. Para obtener más información, vea Analizador de compatibilidad de plataformas.

.NET Standard no está en desuso

.NET Standard sigue siendo necesario para las bibliotecas que se pueden usar en varias implementaciones de .NET. Se recomienda seleccionar .NET Standard como destino en los escenarios siguientes:

  • Use netstandard2.0 para compartir código entre .NET Framework y todas las demás implementaciones de .NET.
  • Use netstandard2.1 para compartir código entre Mono, Xamarin y .NET Core 3.x.

Consulte también