.NET Standard
.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, 9.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
Si tiene como destino .NET Standard, le recomendamos que tenga como destino .NET Standard 2.0, a menos que tenga que admitir una versión anterior. La mayoría de las bibliotecas de uso general no deben necesitar otras API diferentes de .NET Standard 2.0, y .NET Framework no admite .NET Standard 2.1. 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 granular de paquetes NuGet, que crea un gráfico de dependencias de paquetes de gran tamaño y da como resultado una gran cantidad de paquetes que se descargan cuando se compila el proyecto. Para más información, consulte Destinatarios multiplataforma y .NET 5 y .NET Standard más adelante en este artículo.
Nota:
A partir de .NET 9, se emite una advertencia de compilación si el proyecto tiene como destino .NET Standard 1.x. Para obtener más información, consulte Advertencia emitida para destinos de .NET Standard 1.x.
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).
- Lista de API en Markdown
- Ensamblados de referencia, distribuidos como paquetes NuGet y a los que hace referencia el metapaquete NETStandard.Library.
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 tener como destino el marco de .NET Standard mediante el moniker de la plataforma de destino compacto (TFM) de netstandard
; por ejemplo, netstandard1.4
. Las bibliotecas destinadas a ejecutarse en varias implementaciones de .NET deben tener como destino el marco .NET Standard. Para obtener el conjunto más amplio de API, indique netstandard2.0
como destino, puesto que el número de API disponibles se duplicó con creces 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 2019 o Visual Studio 2017 versión 15.3 o posterior instalado en Windows.
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, .NET 8 y .NET 9 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 9, por ejemplo, reflejan esta amplia gama de escenarios:
net9.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. En el caso del código de .NET 9,
net9.0
reemplaza a ynetcoreapp
netstandard
tfMs.net9.0-windows
Este es un ejemplo de un TFM específico del sistema operativo que agrega funcionalidad específica del sistema operativo a todo lo que
net9.0
hace referencia.
Cuándo se debe establecer como destino netx.0
frente a netstandard
Para el código existente que tiene como destino .NET Standard 2.0 o una versión posterior, no es necesario cambiar el TFM a net8.0
o un TFM posterior. .NET 8 y .NET 9 implementan .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, debe tener como destino .NET 5 o una versión posterior. Puede multitarget .NET y .NET Standard para obtener acceso a características más recientes y seguir teniendo la biblioteca disponible para otras implementaciones de .NET.
Nota:
Si el proyecto tiene como destino .NET Standard 1.x, se recomienda volver a colocarlo en .NET Standard 2.0 o .NET 8+. Para obtener más información, consulte Advertencia emitida para destinos de .NET Standard 1.x.
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
net9.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 tener como destino .NET Standard 2.1 o .NET 9. Se recomienda omitir .NET Standard 2.1 y ir directamente a .NET 9. Las bibliotecas más utilizadas tienen 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
net9.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, comonet9.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.