standard net framework entre diferencias clases biblioteca and .net .net-core class-library .net-standard

.net - framework - net standard 2.0 download



¿Cuál es la diferencia entre los tipos de proyectos de.NET Core y.NET Standard Class Library? (10)

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?

¿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 paquete Microsoft.NETCore.CoreCLR 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 en 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 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.

.NET Framework y .NET Core son ambos frameworks.

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

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

Con .NET Standard solo puede hacer un proyecto de biblioteca de clases que no se pueda ejecutar de forma independiente y que otro proyecto ejecutable de .NET Core o .NET Framework haga referencia a él.

.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 el estándar .NET como dependencia a un proyecto Xamarin.Android, Xamarin.iOS, .NET Core Windows / OSX / 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 escritorios. Al agregar esto como una dependencia, puede crear aplicaciones ejecutables en Windows, Linux y OSX. (Aunque la consola solo por ahora, no hay GUI). Entonces .NET Core = .NET Standard + Cosas específicas de escritorio.
También UWP lo usa y el nuevo núcleo ASP.NET también lo usa como una dependencia.

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

Entonces la respuesta corta sería:

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

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 (núcleo, marco, 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/

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.

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.

Como se trata de una biblioteca .NET Standard, se puede usar en cualquier otra biblioteca.

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.

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

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

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

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:

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 será implementado por .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

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 } }

Source

.Net Framework y .Net Core son dos implementaciones diferentes de .Net runtime. 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, 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 ensambles 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. Similar es cierto para .Net Standard 1.1, 1.5, 1.6, 2.0, etc. Siempre y cuando 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 bonitas 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 de SysAdmin 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 continuar trabajando en contra de .Net Marco en Visual Studio en Windows.