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

815

En Visual Studio, hay al menos 3 tipos diferentes de biblioteca de clases que puede crear:

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

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

Entonces, ¿cuál es la diferencia entre Class Library (.NET Standard) y Class Library (.NET Core) , ¿por qué existen ambos y cuándo deberíamos usar uno sobre el otro?

Gigi
fuente
10
Te perdiste uno: Biblioteca de clases (portátil). Core == framework, .NET Standard == portable.
Hans Passant
44
Hubo uno de Xamarin también, pero estos otros no agregan ningún valor a la pregunta :)
Gigi
77
Pues lo hacen. La idea central es que abandonaron el enfoque portátil, ¡sufrió demasiado por el n! un problema en esta manera demasiados perfiles. Así que ahora tienes 7 estándares para elegir. La mayoría no son realmente portátiles en este momento :) .NETCore no se realiza de forma remota, probablemente tome otros dos años en el clip al que van.
Hans Passant
12
OP dijo "al menos 3 tipos diferentes". La publicación fue precisa.
Dan Friedman
1
Estaba confundido por el nombre de Core, que no es un subconjunto central de la plataforma Standard ni Framework. También vemos regularmente ASP asociada con .Net Core. Esto también es muy confuso ...
Alexis Pautrot

Respuestas:

612

¿Cuándo debemos usar uno sobre el otro?

La decisión es una compensación entre compatibilidad y acceso a la API.

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

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

Por ejemplo, una biblioteca que apunte a .NET Standard 1.3 será compatible con aplicaciones que apunten 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 Class Library (.NET Standard) y Class Library (.NET Core)?

La sección de marcos basados ​​en paquetes describe la diferencia.

Compatibilidad: las bibliotecas que se dirigen 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 se dirigen a .NET Core solo pueden ejecutarse en el tiempo de ejecución de .NET Core.

Área de superficie API: las bibliotecas .NET Standard vienen con todo, NETStandard.Librarymientras que las bibliotecas .NET Core vienen con todo Microsoft.NETCore.App. Este último incluye aproximadamente 20 bibliotecas adicionales, algunas de las cuales podemos agregar manualmente a nuestra biblioteca de .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 clase de prueba de unidad sean ejecutables.

¿Por qué existen ambos?

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

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

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

Shaun Luttin
fuente
2
Muy buena respuesta. Sin embargo, una pregunta adicional (se relaciona con esta pregunta : ¿por qué es necesario un modelo de aplicación para ejecutar pruebas unitarias? Este nunca fue el caso en el pasado, cuando utilizamos bibliotecas de clases no ejecutables para almacenar colecciones de pruebas unitarias.
Gigi
3
He actualizado mi respuesta a la pregunta vinculada. TL; DR; En el pasado, las bibliotecas de clases apuntaban al marco completo, que incluye un modelo de aplicación.
Shaun Luttin
Se olvidó de cubrir Class Library (.NET Framework), ¿es compatible con .NET Standard y .NET Core?
Tomás
8
Este diagrama realmente me ayudó a conseguirlo.
jpaugh
1
@BerBar La pregunta original era sobre la diferencia entre .NET Standard y .NET Core. Es por eso que omití los detalles multiplataforma, porque multiplataforma no es una diferencia entre Core y Standard. He mantenido intencionalmente mi respuesta al alcance de la pregunta original.
Shaun Luttin el
396

Una biblioteca de clases de .NET Core se basa en el estándar .NET . Si se desea implementar una biblioteca que es portátil para el .NET Framework ,. .NET Core y Xamarin , elija una biblioteca estándar .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 sabores de .NET Standard

Para preparar sus aplicaciones en el futuro para compartir y reutilizar códigos, preferiría implementar bibliotecas .NET Standard.

Microsoft también recomienda que use .NET Standard en lugar de Portable Class Libraries .

Para citar a MSDN como una 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 situación a continuación: (.NET Framework, Xamarin y ahora aplicaciones con sabor .NET Core)

Ingrese la descripción de la imagen aquí

2. Qué le permitirá la biblioteca estándar .NET (compatibilidad entre marcos)

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

Una biblioteca para gobernarlos a todos

Para los impacientes:

  1. .NET Standard resuelve el problema de intercambio de código para los desarrolladores de .NET en todas las plataformas al brindar 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 tienen que implementar . Esto unifica las plataformas .NET y evita la fragmentación futura .
  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 compatibilidad de compatibilidad para los 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 herramientas para construir bibliotecas .NET multiplataforma.

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

Fuentes: MSDN: Presentación de .NET Standard

usuario919426
fuente
2
ASP.NET Core está un poco fuera de lugar en ese gráfico, ya que se puede usar con .NET Framework completo, no solo .NET Core, porque en realidad se dirige a .NET Standard.
Neme
2
Pero puede crear una aplicación ASP.NET Core con el .NET Framework completo: ASP.NET Core realmente pertenece a la misma capa que .NET Standard. No está limitado solo a .NET Core.
Neme
1
@Neme En primer lugar, sí .Net Core puede incluir bibliotecas .Net Framework pero perder la reutilización multiplataforma (solo para Windows, no * nix u OSX, o reutilizar en Xamarin). Una situación que fue atendida dado que muchos tienen y quieren reutilizar las bibliotecas existentes escritas en el completo .Net Framework sin interés por los beneficios multiplataforma (nivel de sistema operativo y nivel de modelo de aplicación) ... Si todavía siente que estoy mal, tal vez puedas discutir con Microsoft, quien creó esas imágenes ... :-)
user919426
3
No estoy hablando de combinar .NET Core y .NET Framework. Mi punto es que ASP.NET Core no depende en absoluto de .NET Core, a pesar del nombre. Está escrito como una biblioteca que se dirige a .NET Standard, por lo tanto, puede usarlo en cualquier lugar donde pueda usar .NET Standard. Sí, cometieron un error en esa imagen.
Neme
2
@OgrishMan No puede crear un ejecutable en .Net Standard . Solo puede ser una biblioteca de clases, a la que puede hacer referencia otro código de ejecución. No tiene tiempo de ejecución .
user919426
91

Entonces la respuesta corta sería:

IAnimal == .NetStandard (General)
ICat == .NetCore (Less General)
IDog == .NetFramework (Specific / oldest and has the most features)
Joe
fuente
26
@ Joe.wang, como veo, es malo que arruine la relación entre .NET Core y .NET Framework. Si .NET Core es el pájaro, entonces .NET Framework no puede ser el águila (quizás cat sea más adecuado).
Lex Li
8
@LexLi tiene razón, esto enturbia las aguas. .NET Framework no es un subtipo de .NET Core.
Eric Eskildsen
66
esto puede parecer un poco sofisticado pero no exacto
afr0
3
El comentario original de @ Joe sonó más preciso. la respuesta editada por Community lo hizo confuso
Nandun
77
¿Los perros tienen más características que los gatos? Nop :)
hrzafer
71

.NET y .NET Core son dos implementaciones diferentes del tiempo de ejecución .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 de Windows "normal". Incluso en Windows, es posible que tenga el perfil "Cliente" frente al perfil "Completo". Además, y hay otras implementaciones (como Mono ) que tienen sus propios conjuntos de bibliotecas.

.NET Standard es una especificación para la cual los conjuntos de bibliotecas y ensamblados API deben estar disponibles. 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 es cierto para .NET Standard 1.1, 1.5, 1.6, 2.0, etc. Siempre que el tiempo de ejecución brinde soporte para la versión de Standard dirigida por su programa, su programa debería ejecutarse allí.

Un proyecto dirigido a una versión de Standard no podrá hacer uso de características 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 ser sofocante. (Tenga en cuenta un año y medio después: esto está empezando a cambiar, y las versiones recientes de .NET Standard son mucho más agradables y tienen 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 puede ejecutarse con Core, Framework, Mono, etc. Para un proyecto de biblioteca de clase que busque una distribución amplia, es una promesa atractiva. . Para un proyecto de biblioteca de clases utilizado principalmente para fines internos, puede no ser tan preocupante.

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

Joel Coehoorn
fuente
1
Si bien una buena descripción general de lo que son .NET Core y .NET Standard, esta respuesta no responde a la pregunta sobre las bibliotecas de clases dirigidas a cada una de ellas.
Gigi
66
Si ese es su objetivo, la pregunta debe cerrarse como "no está claro lo que está preguntando", ya que siempre habrá demasiados detalles de la situación que juegan en el entorno de una persona determinada para que podamos decirle qué hacer. , o como "Demasiado amplio" si está preguntando sobre el caso general. Todo lo que podemos hacer aquí es brindarle información sobre los productos, para que pueda estar informado para tomar su propia decisión.
Joel Coehoorn
Claramente, ese no es el caso, ya que otro ha respondido con precisión la pregunta. Mi pregunta fue sobre las bibliotecas de clases. Su respuesta fue sobre los marcos.
Gigi
29

.NET Framework y .NET Core son ambos frameworks.

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

Puede hacer 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 pueda ejecutar de manera independiente y que otro proyecto ejecutable de .NET Core o .NET Framework haga referencia a él.

lado B
fuente
20

Espero que esto ayude a comprender la relación entre la superficie 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

Mahbubur Rahman
fuente
17

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

Entonces, con .NET Framework tiene todas las herramientas .NET para trabajar, pero solo puede apuntar a aplicaciones de Windows (UWP, Winforms, 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, Mac). Esto es especialmente útil en las aplicaciones ASP.NET Core, ya que ahora puede alojar Asp.net en Linux (precios de alojamiento más baratos). 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 admitan, 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. Actualización: también es posible apuntar a clientes web con la plataforma UNO y Blazor (aunque ambos son un poco experimentales en este momento).

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

Compartió tanto el servidor como el cliente:

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

Como es una biblioteca estándar .NET, se puede usar 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 la misma validación se aplica en el servidor y 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 estándar .NET (también podría ser 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 estándar .NET que maneja la lógica de ViewModels. Utilizado en todas las vistas.

  • Una aplicación .NET Framework WPF que maneja las vistas WPF para una aplicación de Windows. Actualización: 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 estándar .NET que maneja las vistas de formularios Xamarin.

  • Un proyecto Xamarin para 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 (Client API y ViewModels) y simplemente crear vistas sin lógica para las aplicaciones WPF, Xamarin e IOS.

Dev Kevin
fuente
2
Creo que esta es una mejor respuesta ya que incorpora el mundo real.
J Weezy
12

.NET Standard: piense en ello como una gran biblioteca estándar. Cuando se usa esto como una dependencia, solo puede crear bibliotecas (.DLL), no ejecutables. Se puede agregar una biblioteca hecha con .NET estándar como dependencia a un proyecto 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 se implementaron y otras quedaron en desuso. Extiende el estándar .NET con funciones adicionales, pero solo se ejecuta en equipos de escritorio . Al agregar esto como una dependencia, puede crear aplicaciones ejecutables en Windows, Linux y OS X. (Aunque la consola solo por ahora, no hay GUI). Entonces .NET Core = .NET Standard + material específico de escritorio.

También UWP lo usa y el nuevo ASP.NET Core también lo usa como una dependencia.

Peter Mortensen
fuente
8

.NET Standard existe principalmente para mejorar el intercambio de código y hacer que las API disponibles en cada implementación de .NET sean más consistentes.

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

ARP
fuente
2

Las respuestas anteriores pueden describir la mejor comprensión acerca de la diferencia entre el núcleo neto, el estándar neto y el marco neto, por lo que solo quiero compartir mi experiencia al elegir esto sobre eso.

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

La siguiente razón es que estábamos usando Active Report que no es compatible con .NET Core. Por lo tanto, queremos construir una biblioteca de infraestructura que pueda usarse tanto para .NET Core (asp.net core) como para Windows Service and Reporting (.NET Framework) -> Es por eso que elegimos .NET Standard para este tipo de biblioteca. Elegir .NET estándar significa que debe considerar cuidadosamente que cada clase en la biblioteca debe ser simple y cruzada .NET (core, framework, estándar).

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, Windows Services (ahora con .NET 3.0 es compatible).
  • .NET Core para ASP.NET Core, por supuesto.

Microsoft acaba de anunciar .NET 5: https://devblogs.microsoft.com/dotnet/introducing-net-5/

toannm
fuente
@Gigi Lea atentamente mi respuesta, dije que fue cuando .NET Core en una versión 1.0 y en este caso queremos diseñar una solución para combinar .NET core y .NET framework. ASP.NET Core admite .NET Framework desde 2.0 anterior. Mi respuesta es una historia cuando tienes que lidiar con múltiples versiones de .NET. Así que no puedo entender por qué tienes un voto negativo cuando no entiendes la situación correctamente.
toannm
Gracias por su respuesta: leí su respuesta y leí la parte en la que se refería a .NET Core 1.0. Sin embargo, no tomé eso como un prerrequisito para interpretar sus conclusiones, lo que de lo contrario confundiría a las personas que leen con las versiones actuales. Además, parece que mi comentario fue bombardeado por la policía de Stack Overflow, lo cual es una lástima a la que me he acostumbrado en este sitio.
Gigi
0

.NET Framework Windows Form, ASP.NET y la aplicación WPF deben desarrollarse utilizando la biblioteca .NET Framework

Las aplicaciones .NET Standard Xamarin, IOs y MAC OSx deben eliminarse usando la biblioteca .NET Standard

.NET Core
Universal Windows Platform (UWP) y la aplicación Linux deben desarrollarse utilizando la biblioteca .NET Core. La API se implementa en C ++ y puede usar los lenguajes C ++, VB.NET, C #, F # y Javascript .NET

Fabio Panzironi
fuente
0

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

Ömer Özkan
fuente
Su respuesta no está completamente relacionada con la pregunta. por favor revisa
Programador Avid