.NET Estándar

.NET Estándar es una especificación formal de las API de .NET que están disponibles en varias implementaciones de .NET. La motivación de .NET Estándar era 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 Estándar en la mayoría de los escenarios. Sin embargo, si desea 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án nuevas versiones de .NET Standard, pero .NET 5 y todas las versiones posteriores seguirán admitiendo .NET Standard 2.1 y versiones anteriores.

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

.NET versiones estándar

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

Apuntar a una versión superior de .NET Standard permite a una biblioteca usar más APIs, pero significa que solo se puede utilizar 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 .NET versión estándar.

¿Qué versión de estándar .NET a la que dirigirse?

Si el destino es .NET Estándar, le recomendamos que tenga como destino .NET Standard 2.0, a menos que necesite admitir una versión anterior. La mayoría de las bibliotecas de uso general no deben necesitar API fuera de .NET Standard 2.0 y .NET Framework no admite .NET Standard 2.1. .NET Standard 2.0 es compatible con todas las plataformas modernas y es la manera recomendada de admitir varias plataformas con un destino.

Si necesita admitir .NET Standard 1.x, recomendamos que también tenga como objetivo .NET Standard 2.0. .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 obtener más información, vea orientación multiplataforma y .NET 5+ y .NET Standard más adelante en este artículo.

.NET reglas de control de versiones estándar

Hay dos reglas de control de versiones principales:

• Aditivo: las versiones estándar de .NET son círculos lógicos concéntricos: las versiones más altas incorporan todas las API de versiones anteriores. No hay ningún cambio importante entre versiones.
• Inmutable: una vez lanzadas, las versiones de .NET Standard están congeladas.

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

Especificación

La especificación .NET Estándar es un conjunto estandarizado de API. Los implementadores de .NET mantienen la especificación, específicamente Microsoft (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 (ahora archivado) repositorio dotnet/standard define las API de .NET Standard.

El metapaquete NETStandard.Library (source) describe el conjunto de bibliotecas que definen (en parte) una o varias versiones estándar de .NET.

Un componente determinado, como , describe lo siguiente:

• Parte de .NET Estándar (solo su ámbito).
• Varias versiones de .NET Estándar, 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 vehículo de distribución principal para los ensamblados de referencia estándar de .NET es paquetes NuGet. Las implementaciones se entregan de varias maneras, adecuadas para cada implementación de .NET.

Los paquetes NuGet tienen como destino uno o varios frameworks. .NET paquetes Estándar tienen como destino el marco ".NET Estándar". Puede apuntar a la plataforma .NET Standard utilizando el netstandardmoniker del marco de trabajo de destino compacto (TFM), por ejemplo, netstandard1.4. Las bibliotecas diseñadas para ejecutarse en varias implementaciones de .NET deben tener como destino el marco estándar de .NET. Para el conjunto más amplio de API, apunte a netstandard2.0, ya que el número de API disponibles aumentó más del doble entre .NET Standard 1.6 y 2.0.

El metapaquete />

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 Estándar no es específico de ninguna .NET implementación, ni coincide con el esquema de control de versiones de cualquiera de esas implementaciones.

Como se indicó anteriormente, no habrá nuevas versiones .NET Estándar después de la versión 2.1.

.NET estándar de destino

Puede construir Bibliotecas Estándar de .NET mediante una combinación del netstandard marco y el NETStandard.Library metapaquete.

modo de compatibilidad de .NET Framework

A partir de .NET Standard 2.0, se introdujo el modo de compatibilidad de .NET Framework. Este modo de compatibilidad permite que .NET proyectos estándar hagan referencia a bibliotecas de .NET Framework como si se compilaran para .NET Estándar. Hacer referencia a bibliotecas de .NET Framework no funciona para todos los proyectos, como las bibliotecas que usan api de Windows Presentation Foundation (WPF).

Para obtener más información, vea modo de compatibilidad de .NET Framework.

.NET bibliotecas estándar y Visual Studio

Para compilar bibliotecas estándar .NET en Visual Studio, asegúrese de que tiene Visual Studio 2019 o posterior o Visual Studio 2017 versión 15.3 o posterior instalada en Windows.

Si solo necesita consumir bibliotecas de .NET Standard 2.0 en los 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 NuGet para Visual Studio 2015 desde la página NuGet.

.NET 5+ y .NET Estándar

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

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

• net10.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 hace referencia.

Cuándo se debe establecer como destino frente a

Para el código existente que tiene como destino .NET Standard 2.0 o posterior, no es necesario cambiar el TFM a net8.0 o un TFM posterior. .NET 8, .NET 9 y .NET 10 implementan .NET Standard 2.1 y versiones anteriores. La única razón para volver a establecer el destino de .NET Estándar 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 utilizar .NET y .NET Estándar para objetivos múltiples, lo que le permitirá acceder a características más recientes y mantener su biblioteca disponible para otras implementaciones de .NET.

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

• Componentes de la aplicación

  Si usa bibliotecas para dividir una aplicación en varios componentes, se recomienda usar . Por motivos de simplicidad, es mejor mantener todos los proyectos que componen la aplicación en la misma versión de .NET. Después, puede asumir 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 versión más reciente compatible con .NET Framework, por lo que ofrece un buen alcance con un conjunto de características bastante grande. No se recomienda establecer como destino .NET Standard 1.x, ya que limitaría el conjunto de características disponible para un aumento mínimo del alcance.

  Si no necesita admitir .NET Framework, puede tener como destino .NET Standard 2.1 o .NET 10. Le recomendamos que omita .NET Standard 2.1 y vaya directamente a .NET 10. La mayoría de las bibliotecas más utilizadas son de destinos múltiples para .NET Standard 2.0 y .NET 5+. La compatibilidad con .NET Standard 2.0 ofrece el máximo alcance, mientras que el soporte para .NET 5+ asegura que se puedan aprovechar las características de plataforma más recientes para los clientes que ya están en .NET 5+.

problemas de .NET Estándar

Estos son algunos problemas con .NET Estándar 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 Estándar se creó como un conjunto de API que todas las implementaciones de .NET tendrían que admitir, por lo que había un proceso de revisión de las propuestas para agregar nuevas API. El objetivo era estandarizar solo las API que se podían implementar en todas las plataformas actuales y futuras .NET. 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. A continuación, esperaría incluso más tiempo a que se admita ampliamente la nueva versión de .NET Estándar.

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

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

  Solution en .NET 5+: No hay ninguna separación entre una especificación de 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 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 . 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 ninguna tabla equivalente de número de versión, como la de .NET Estándar.

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

  .NET Standard expone API específicas de la plataforma. Tu código podría compilarse sin errores y parecer ser portátil a cualquier plataforma aunque no lo sea. Cuando se ejecuta en una plataforma que no tiene una implementación para una API determinada, obtendrá errores en tiempo de ejecución.

  Solution en .NET 5+: Los SDK de .NET 5+ incluyen analizadores de código 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á obsoleto

.NET Estándar sigue siendo necesario para las bibliotecas que se pueden usar en varias implementaciones de .NET. Le recomendamos que tenga como destino .NET Estándar 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 y .NET Core 3.x.

Consulte también

• Versiones de .NET Standard (source)
• .NET versiones estándar (interfaz de usuario interactiva)
• Build a .NET standard library
• Orientación multiplataforma