¿Cuál es la diferencia entre los tipos de proyecto .NET Core y .NET Standard Class Library?

En Visual Studio, hay al menos tres tipos diferentes de bibliotecas de clases que puede crear:

• Biblioteca de clases (.NET Framework)
• Biblioteca de clases (.NET Standard)
• Biblioteca de clases (.NET Core)

Si bien el primero es lo que hemos estado usando durante años, un punto importante de confusión que he tenido es cuándo usar los tipos de biblioteca de clases .NET Standard y .NET Core. Esto me ha mordido recientemente al intentar apuntar a diferentes versiones de framework y crear un proyecto de prueba unitaria .

Entonces, ¿cuál es la diferencia entre la biblioteca de clases (.NET Standard) y la biblioteca de clases (.NET Core) , por qué existen ambas y cuándo debemos usar una sobre la otra?

¿Cuándo debemos usar uno sobre el otro?

La decisión es un compromiso entre la compatibilidad y el acceso a la API.

Utilice una biblioteca .NET Standard cuando desee aumentar la cantidad de aplicaciones que serán compatibles con su biblioteca, y está de acuerdo con una disminución en el área de superficie de la API .NET a la que puede acceder su biblioteca.

Use una biblioteca .NET Core cuando desee aumentar el área de superficie de la API .NET a la que puede acceder su biblioteca, y está de acuerdo con permitir que solo las aplicaciones .NET Core sean compatibles con su biblioteca.

Por ejemplo, una biblioteca destinada a .NET Standard 1.3 será compatible con aplicaciones destinadas a .NET Framework 4.6, .NET Core 1.0, Universal Windows Platform 10.0 y cualquier otra plataforma que admita .NET Standard 1.3. Sin embargo, la biblioteca no tendrá acceso a algunas partes de la API .NET. Por ejemplo, el Microsoft.NETCore.CoreCLRpaquete es compatible con .NET Core, pero no con .NET Standard.

¿Cuál es la diferencia entre la biblioteca de clases (.NET Standard) y la biblioteca de clases (.NET Core)?

Compatibilidad: las bibliotecas destinadas a .NET Standard se ejecutarán en cualquier tiempo de ejecución compatible con .NET Standard, como .NET Core, .NET Framework, Mono / Xamarin . Por otro lado, las bibliotecas que tienen como destino .NET Core solo se pueden ejecutar en el tiempo de ejecución de .NET Core.

Área de superficie de API: las bibliotecas .NET Standard vienen con todo NETStandard.Library, mientras que las bibliotecas .NET Core vienen con todo en Microsoft.NETCore.App. Este último incluye aproximadamente 20 bibliotecas adicionales, algunas de las cuales podemos agregar manualmente a nuestra biblioteca .NET Standard (como System.Threading.Thread) y algunas de las cuales no son compatibles con .NET Standard (como Microsoft.NETCore.CoreCLR).

Además, las bibliotecas .NET Core especifican un tiempo de ejecución y vienen con un modelo de aplicación. Eso es importante, por ejemplo, para hacer que las bibliotecas de clases de pruebas unitarias se puedan ejecutar.

¿Por qué existen ambos?

Ignorando las bibliotecas por un momento, la razón por la que existe .NET Standard es por la portabilidad; define un conjunto de API que las plataformas .NET aceptan implementar. Cualquier plataforma que implemente un .NET Standard es compatible con las bibliotecas que se dirigen a ese .NET Standard. Una de esas plataformas compatibles es .NET Core.

Volviendo a las bibliotecas, las plantillas de biblioteca .NET Standard existen para ejecutarse en múltiples tiempos de ejecución (a expensas del área de superficie de la API). Por el contrario, las plantillas de biblioteca de .NET Core existen para acceder a más superficie de la API (a expensas de la compatibilidad) y para especificar una plataforma contra la cual compilar un ejecutable.

Aquí hay una matriz interactiva que muestra qué .NET Standard admite qué implementación (es) de .NET y cuánta superficie API está disponible.

Una biblioteca de clases de .NET Core se basa en .NET Standard . Si desea implementar una biblioteca que sea portátil para .NET Framework , .NET Core y Xamarin , elija una biblioteca estándar de .NET

.NET Core finalmente implementará .NET Standard 2 (al igual que Xamarin y .NET Framework )

.NET Core , Xamarin y .NET Framework pueden, por lo tanto, identificarse como versiones de .NET Standard

Para preparar sus aplicaciones para el uso compartido y la reutilización de código en el futuro, prefiere implementar bibliotecas .NET Standard.

Microsoft también recomienda que utilice .NET Standard en lugar de Bibliotecas de clases portátiles .

Para citar a MSDN como fuente autorizada, .NET Standard pretende ser una biblioteca para gobernarlos a todos . Como las imágenes valen más que mil palabras, lo siguiente aclarará las cosas:

1. Su escenario de aplicación actual (fragmentado)

Como la mayoría de nosotros, probablemente se encuentre en la siguiente situación: (.NET Framework, Xamarin y ahora aplicaciones con sabor a .NET Core)

2. Qué le permitirá .NET Standard Library (compatibilidad entre marcos)

La implementación de una biblioteca estándar .NET permite compartir código en todos estos sabores diferentes:

Para los impacientes:

1. .NET Standard resuelve el problema del uso compartido de código para los desarrolladores de .NET en todas las plataformas al ofrecer todas las API que espera y ama en los entornos que necesita: aplicaciones de escritorio, aplicaciones y juegos móviles y servicios en la nube:
2. .NET Standard es un conjunto de API que todas las plataformas .NET deben implementar . Esto unifica las plataformas .NET y evita una futura fragmentación .
3. .NET Standard 2.0 se llevará a cabo mediante .NET Framework ,. NET Core y Xamarin . Para .NET Core , esto agregará muchas de las API existentes que se han solicitado.
4. .NET Standard 2.0 incluye una corrección de compatibilidad para los archivos binarios de .NET Framework , lo que aumenta significativamente el conjunto de bibliotecas a las que puede hacer referencia desde sus bibliotecas .NET Standard.
5. .NET Standard reemplazará a las bibliotecas de clases portátiles (PCL) como la historia de las herramientas para crear bibliotecas .NET multiplataforma.

Para obtener una tabla que lo ayude a comprender cuál es la versión más alta de .NET Standard a la que puede dirigirse, según las plataformas .NET en las que desea ejecutar, diríjase aquí .

Fuentes: MSDN: Introducción a .NET Standard

La respuesta corta sería:

IAnimal == .NetStandard (General)
ICat == .NetCore (Less general)
IDog == .NetFramework (Specific / oldest and has the most features)

.NET y .NET Core son dos implementaciones diferentes del tiempo de ejecución de .NET. Tanto Core como Framework (pero especialmente Framework) tienen diferentes perfiles que incluyen selecciones más grandes o más pequeñas (o simplemente diferentes) de las muchas API y ensamblados que Microsoft ha creado para .NET, dependiendo de dónde estén instalados y en qué perfil.

Por ejemplo, hay algunas API diferentes disponibles en las aplicaciones universales de Windows que en el perfil "normal" de Windows. Incluso en Windows, es posible que tenga el perfil "Cliente" frente al perfil "Completo". Además, existen otras implementaciones (como Mono ) que tienen sus propios conjuntos de bibliotecas.

.NET Standard es una especificación para la que deben estar disponibles conjuntos de bibliotecas y ensamblados de API. Una aplicación escrita para .NET Standard 1.0 debería poder compilarse y ejecutarse con cualquier versión de Framework, Core, Mono, etc., que anuncie soporte para la colección de bibliotecas .NET Standard 1.0. Lo mismo ocurre con .NET Standard 1.1, 1.5, 1.6, 2.0, etc. Siempre que el tiempo de ejecución proporcione soporte para la versión de Standard a la que apunta su programa, su programa debería ejecutarse allí.

Un proyecto destinado a una versión del estándar no podrá utilizar funciones que no estén incluidas en esa revisión del estándar. Esto no significa que no pueda tomar dependencias de otros ensamblados o API publicadas por otros proveedores (es decir, elementos en NuGet). Pero sí significa que cualquier dependencia que tome también debe incluir soporte para su versión de .NET Standard. .NET Standard está evolucionando rápidamente, pero aún es lo suficientemente nuevo y se preocupa lo suficiente por algunos de los perfiles de tiempo de ejecución más pequeños, por lo que esta limitación puede resultar asfixiante. (Tenga en cuenta que un año y medio después: esto está comenzando a cambiar, y las versiones recientes de .NET Standard son mucho más agradables y con más funciones).

Por otro lado, una aplicación dirigida a Standard debería poder usarse en más situaciones de implementación, ya que en teoría se puede ejecutar con Core, Framework, Mono, etc. Para un proyecto de biblioteca de clases que busca una amplia distribución, esa es una promesa atractiva . En el caso de un proyecto de biblioteca de clases utilizado principalmente para fines internos, puede que no sea tan preocupante.

.NET Standard también puede ser útil en situaciones en las que el equipo de administrador del sistema desea pasar de ASP.NET en Windows a ASP.NET para .NET Core en Linux por razones filosóficas o de costo, pero el equipo de desarrollo quiere seguir trabajando en contra. NET Framework en Visual Studio en Windows.

.NET Framework y .NET Core son ambos marcos.

.NET Standard es un estándar (en otras palabras, una especificación).

Puede crear un proyecto ejecutable (como una aplicación de consola o una aplicación ASP.NET) con .NET Framework y .NET Core, pero no con .NET Standard.

Con .NET Standard, solo puede crear un proyecto de biblioteca de clases que no se puede ejecutar de forma independiente y debe ser referenciado por otro proyecto ejecutable de .NET Core o .NET Framework.

Otra forma de explicar la diferencia podría ser con ejemplos del mundo real, ya que la mayoría de nosotros, simples mortales, usaremos herramientas y marcos existentes ( Xamarin , Unity , etc.) para hacer el trabajo.

Entonces, con .NET Framework tiene todas las herramientas .NET con las que trabajar, pero solo puede apuntar a aplicaciones de Windows ( UWP , Windows Forms , ASP.NET , etc.). Dado que .NET Framework es de código cerrado, no hay mucho que hacer al respecto.

Con .NET Core tiene menos herramientas, pero puede apuntar a las principales plataformas de escritorio (Windows, Linux y Mac). Esto es especialmente útil en aplicaciones ASP.NET Core, ya que ahora puede alojar ASP.NET en Linux (precios de alojamiento más económicos). Ahora, dado que .NET Core fue de código abierto, es técnicamente posible desarrollar bibliotecas para otras plataformas. Pero como no hay marcos que lo respalden, no creo que sea una buena idea.

Con .NET Standard tiene incluso menos herramientas, pero puede apuntar a todas / la mayoría de las plataformas. Puede apuntar a dispositivos móviles gracias a Xamarin, e incluso puede apuntar a consolas de juegos gracias a Mono / Unity. También es posible apuntar a clientes web con la plataforma UNO y Blazor (aunque ambos son algo experimentales en este momento).

En una aplicación del mundo real, es posible que deba utilizarlos todos. Por ejemplo, desarrollé una aplicación de punto de venta que tenía la siguiente arquitectura:

Compartió servidor y slient:

• Una biblioteca .NET Standard que maneja los modelos de mi aplicación.
• Una biblioteca .NET Standard que maneja la validación de los datos enviados por los clientes.

Dado que es una biblioteca .NET Standard, se puede utilizar en cualquier otro proyecto (cliente y servidor).

También es una buena ventaja tener la validación en una biblioteca estándar .NET, ya que puedo estar seguro de que se aplica la misma validación en el servidor y en el cliente. El servidor es obligatorio, mientras que el cliente es opcional y útil para reducir el tráfico.

Lado del servidor (API web):

• Una biblioteca .NET Standard (también podría ser .NET Core) que maneja todas las conexiones de la base de datos.

• Un proyecto .NET Core que maneja la API Rest y hace uso de la biblioteca de la base de datos.

Como esto se desarrolla en .NET Core, puedo alojar la aplicación en un servidor Linux.

Lado del cliente ( MVVM con WPF + Xamarin.Forms Android / iOS):

• Una biblioteca .NET Standard que maneja la conexión API del cliente.

• Una biblioteca .NET Standard que maneja la lógica de ViewModels . Se utiliza en todas las vistas.

• Una aplicación .NET Framework WPF que controla las vistas de WPF para una aplicación de Windows. Las aplicaciones WPF pueden ser .NET core ahora, aunque actualmente solo funcionan en Windows. AvaloniaUI es una buena alternativa para crear aplicaciones GUI de escritorio para otras plataformas de escritorio.

• Una biblioteca .NET Standard que controla las vistas de formularios de Xamarin.

• Un proyecto de Xamarin Android y Xamarin iOS .

Entonces, puede ver que hay una gran ventaja aquí en el lado del cliente de la aplicación, ya que puedo reutilizar ambas bibliotecas .NET Standard ( API cliente y ViewModels) y simplemente crear vistas sin lógica para las aplicaciones WPF, Xamarin e iOS.

Espero que esto ayude a comprender la relación entre la superficie de la API estándar de .NET y otras plataformas .NET . Cada interfaz representa un marco de destino y los métodos representan grupos de API disponibles en ese marco de destino.

namespace Analogy
{
    // .NET Standard

    interface INetStandard10
    {
        void Primitives();
        void Reflection();
        void Tasks();
        void Xml();
        void Collections();
        void Linq();
    }

    interface INetStandard11 : INetStandard10
    {
        void ConcurrentCollections();
        void LinqParallel();
        void Compression();
        void HttpClient();
    }

    interface INetStandard12 : INetStandard11
    {
        void ThreadingTimer();
    }

    interface INetStandard13 : INetStandard12
    {
        //.NET Standard 1.3 specific APIs
    }

    // And so on ...


    // .NET Framework

    interface INetFramework45 : INetStandard11
    {
        void FileSystem();
        void Console();
        void ThreadPool();
        void Crypto();
        void WebSockets();
        void Process();
        void Drawing();
        void SystemWeb();
        void WPF();
        void WindowsForms();
        void WCF();
    }

    interface INetFramework451 : INetFramework45, INetStandard12
    {
        // .NET Framework 4.5.1 specific APIs
    }

    interface INetFramework452 : INetFramework451, INetStandard12
    {
        // .NET Framework 4.5.2 specific APIs
    }

    interface INetFramework46 : INetFramework452, INetStandard13
    {
        // .NET Framework 4.6 specific APIs
    }

    interface INetFramework461 : INetFramework46, INetStandard14
    {
        // .NET Framework 4.6.1 specific APIs
    }

    interface INetFramework462 : INetFramework461, INetStandard15
    {
        // .NET Framework 4.6.2 specific APIs
    }

    // .NET Core
    interface INetCoreApp10 : INetStandard15
    {
        // TODO: .NET Core 1.0 specific APIs
    }
    // Windows Universal Platform
    interface IWindowsUniversalPlatform : INetStandard13
    {
        void GPS();
        void Xaml();
    }

    // Xamarin
    interface IXamarinIOS : INetStandard15
    {
        void AppleAPIs();
    }

    interface IXamarinAndroid : INetStandard15
    {
        void GoogleAPIs();
    }
    // Future platform

    interface ISomeFuturePlatform : INetStandard13
    {
        // A future platform chooses to implement a specific .NET Standard version.
        // All libraries that target that version are instantly compatible with this new
        // platform
    }

}

Fuente

.NET Standard: Piense en ello como una gran biblioteca estándar. Al usar esto como una dependencia, solo puede crear bibliotecas (.DLL), no ejecutables. Una biblioteca creada con el estándar .NET como dependencia se puede agregar a un proyecto de Xamarin.Android, Xamarin.iOS, .NET Core Windows / OS X / Linux.

.NET Core: Piense en ello como la continuación del antiguo marco .NET, solo es de código abierto y algunas cosas aún no están implementadas y otras quedaron obsoletas. Extiende el estándar .NET con funciones adicionales, pero solo se ejecuta en computadoras de escritorio . Al agregar esto como una dependencia, puede crear aplicaciones ejecutables en Windows, Linux y OS X. (Aunque la consola es solo por ahora, no hay GUI). Entonces .NET Core = .NET Standard + cosas específicas de escritorio.

Además, UWP lo usa y el nuevo ASP.NET Core también lo usa como dependencia.

.NET Standard existe principalmente para mejorar el uso compartido de código y hacer que las API estén disponibles en cada implementación de .NET más coherente.

Mientras creamos bibliotecas, podemos tener el objetivo como .NET Standard 2.0 para que la biblioteca creada sea compatible con diferentes versiones de .NET Framework, incluidas .NET Core, Mono , etc.

Las respuestas anteriores pueden describir la mejor comprensión sobre la diferencia entre .NET Core, .NET Standard y .NET Framework, por lo que solo quiero compartir mi experiencia al elegir esto en lugar de eso.

En el proyecto que necesita mezclar entre .NET Framework, .NET Core y .NET Standard. Por ejemplo, en el momento en que compilamos el sistema con .NET Core 1.0, no hay soporte para el alojamiento de Windows Services con .NET Core.

La siguiente razón es que estábamos usando Active Report, que no es compatible con .NET Core.

Así que queremos construir una biblioteca de infraestructura que se pueda usar tanto para .NET Core (ASP.NET Core) como para el servicio e informes de Windows (.NET Framework) -> Es por eso que elegimos .NET Standard para este tipo de biblioteca. Elegir el estándar .NET significa que debe considerar cuidadosamente que todas las clases de la biblioteca deben ser simples y cruzadas .NET (Core, Framework y Standard).

Conclusión:

• .NET Standard para la biblioteca de infraestructura y común compartido. Esta biblioteca puede ser referenciada por .NET Framework y .NET Core.
• .NET Framework para tecnologías no compatibles como Active Report, Window Services (ahora con .NET 3.0 es compatible).
• .NET Core para ASP.NET Core, por supuesto.

Microsoft acaba de anunciar .NET 5: Presentamos .NET 5

Una biblioteca de clases de .NET Core se basa en .NET Standard. Si desea implementar una biblioteca que sea portátil para .NET Framework, .NET Core y Xamarin, elija una biblioteca estándar de .NET.

.NET Framework

Las aplicaciones Windows Forms , ASP.NET y WPF deben desarrollarse utilizando la biblioteca .NET Framework.

.NET estándar

La aplicación Xamarin, iOS y Mac OS X debe desarrollarse usando la biblioteca .NET Standard

.NET Core

La plataforma universal de Windows (UWP) y la aplicación de Linux deben desarrollarse con la biblioteca .NET Core. La API está implementada en C ++ y puede usar los lenguajes C ++, VB.NET, C #, F # y JavaScript .NET