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

937

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?

9
  • 12
    Te perdiste uno: Biblioteca de clases (portátil). Core == framework, .NET Standard == portable. Hans Passant 21/03/2017 a las 22:41
  • 4
    También hubo uno de Xamarin, pero estos otros no agregan ningún valor a la pregunta :)Gigi 21/03/2017 a las 22:42
  • 7
    Bueno, lo hacen. La idea central es que renunciaron al enfoque portátil, ¡sufrió demasiado con el n! un problema en esta manera demasiados perfiles. Así que ahora tiene 7 estándares para elegir. La mayoría no son realmente portátiles en este momento :) .NETCore no está hecho por mucho tiempo, probablemente tome otros dos años en el momento en que van. Hans Passant 21/03/2017 a las 22:47
  • 15
    OP dijo "al menos 3 tipos diferentes". La publicación fue precisa. Dan Friedman 19 de septiembre de 2017 a las 20:49
  • 3
    Estaba confundido por el nombre de Core, que no es un subconjunto central ni de la plataforma Standard ni de Framework. También vemos regularmente ASP asociado con .Net Core. Esto también es muy confuso ...Alexis Pautrot 30 de mayo de 2018 a las 14:53
709

When should we use one over the other?

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.

What is the difference between Class Library (.NET Standard) and Class Library (.NET Core)?

Compatibilidad: las bibliotecas que tienen como destino .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 la API: las bibliotecas .NET Standard incluyen todo NETStandard.Library, mientras que las bibliotecas .NET Core lo incluyen todo 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.

Why do both exist?

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 área de superficie de 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.

14
  • 2
    Muy buena respuesta. Una pregunta adicional, aunque (se refiere a esta pregunta : ¿por qué es un modelo de aplicación necesaria para ejecutar pruebas unitarias Esto nunca fue el caso en el pasado, cuando utilizamos las bibliotecas de clases no ejecutables a las colecciones de retención de pruebas unitarias?.Gigi 22 de marzo de 2017 a las 8:22
  • 3
    Actualicé mi respuesta a la pregunta vinculada. TL; DR; En el pasado, las bibliotecas de clases tenían como objetivo el marco completo, que incluye un modelo de aplicación. Shaun Luttin 22/03/2017 a las 16:37
  • Olvidó cubrir la Biblioteca de clases (.NET Framework), ¿es compatible con .NET Standard y .NET Core? Tomas 11/07/18 a las 11:35
  • 10
    Este diagrama realmente me ayudó a conseguirlo. jpaugh 13/11/18 a las 15:31
  • 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. Intencionalmente mantuve mi respuesta dentro del alcance de la pregunta original. Shaun Luttin 1 de ene. De 2019 a las 22:34
437

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, preferiría 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 dejará las cosas muy claras:

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)

Ingrese la descripción de la imagen aquí

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

La implementación de una biblioteca estándar de .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 del uso compartido 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 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 binarios de .NET Framework , lo que aumenta significativamente el conjunto de bibliotecas a las que puede hacer referencia desde sus bibliotecas de .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

11
  • 2
    ASP.NET Core está un poco fuera de lugar en ese gráfico, ya que se puede usar con el .NET Framework completo, no solo .NET Core, porque en realidad apunta a .NET Standard. Neme 20/08/2017 a las 11:33
  • 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 20 de agosto de 2017 a las 18:29
  • 1
    @Neme En primer lugar, sí .Net Core puede incluir bibliotecas de .Net Framework pero pierde la reutilización multiplataforma (solo para Windows, no * nix ni OSX, ni la reutilización en Xamarin). Una situación que se solucionó dado que muchos tienen y quieren reutilizar las bibliotecas existentes escritas en Net Framework completo sin interés en los beneficios multiplataforma (nivel de sistema operativo y nivel de modelo de aplicación) ... mal, tal vez puedas discutir con Microsoft, quien fue el autor de esas imágenes ... :-)user919426 20/08/2017 a las 19:47
  • 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 apunta a .NET Standard, por lo tanto, puede usarlo en cualquier lugar donde pueda usar .NET Standard. Sí, se equivocaron en esa imagen. Neme 20/08/2017 a las 19:50
  • 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 6 de febrero de 2019 a las 5:14
97

La respuesta corta sería:

IAnimal == .NetStandard (General)
ICat == .NetCore (Less general)
IDog == .NetFramework (Specific / oldest and has the most features)
9
  • 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 (tal vez el gato sea más adecuado). Lex Li 27 de junio de 2017 a las 0:17
  • 8
    @LexLi tiene razón, esto enturbia las aguas. .NET Framework no es un subtipo de .NET Core. Eric Eskildsen 19/07/2017 a las 16:54
  • 6
    esto puede parecer un poco elegante pero no exactoafr0 11 de septiembre de 2017 a las 6:28
  • 4
    El comentario original de @Joe sonaba más preciso. La respuesta editada por Community lo hizo confusoNandun 11/01/18 a las 15:53
  • 8
    ¿Los perros tienen más características que los gatos? Nop :)hrzafer 27/07/2018 a las 16:13
74

.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 instaladas 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á hacer uso de 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 . Para un proyecto centrado en el usuario final destinado principalmente a una audiencia interna, 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.

3
  • 1
    Si bien es 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 uno de ellos. Gigi 22 de marzo de 2017 a las 8:17
  • 8
    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 influyen en el entorno de una persona determinada para que podamos simplemente decirle qué hacer. o como "Demasiado amplio" si pregunta 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 1 de mayo de 2017 a las 16:28
  • Claramente, ese no es el caso, ya que otro ha respondido con precisión a la pregunta. Mi pregunta fue sobre las bibliotecas de clases. Tu respuesta fue sobre los marcos. Gigi 2 de mayo de 2017 a las 18:28
33

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

25

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

23

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 usarlos todos. Por ejemplo, desarrollé una aplicación de punto de venta que tenía la siguiente arquitectura:

Compartido 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 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 de .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 de la API del cliente.

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

  • Una aplicación de .NET Framework WPF que maneja 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 .

Así se puede ver que hay una gran ventaja en este caso en el lado cliente de la aplicación, ya que puedo volver a utilizar las dos bibliotecas .NET estándar ( cliente API y ViewModels) y acaba de hacer puntos de vista con ninguna lógica para las aplicaciones de WPF, Xamarin y iOS.

1
  • 2
    Creo que esta es una mejor respuesta ya que incorpora el mundo real. J Weezy 19 de mayo de 2019 a las 20:14
12

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

8

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

2

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

2
  • @Gigi Por favor, lea mi respuesta con atención, dije que fue cuando .NET Core en una versión 1.0 y en este caso queremos diseñar una solución para combinar tanto .NET core como .NET framework. ASP.NET Core es compatible con .NET Framework desde 2.0 arriba. 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 30 de mayo de 2019 a las 7:25
  • Gracias por su respuesta. Leí su respuesta y leí la parte en la que se refirió a .NET Core 1.0. Sin embargo, no tomé eso como un requisito previo para interpretar sus conclusiones, que de otro modo engañarían a las personas que leen con la versión actual. Además, parece que mi comentario fue bombardeado por la policía de Stack Overflow, lo cual es una pena a lo que me he acostumbrado en este sitio. Gigi 30 de mayo de 2019 a las 18:25
0

.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 utilizando la biblioteca estándar .NET

.NET Core

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

0

.NET Core .NET Core es una implementación gratuita, multiplataforma y de código abierto del marco administrado. Admite cuatro tipos de aplicaciones: consola, ASP.NET Core, nube y Plataforma universal de Windows (UWP). Windows Forms y Windows Presentation Foundation (WPF) no forman parte de .NET Core.

Técnicamente, .NET Core solo admite aplicaciones de consola. ASP.NET Core y UWP son modelos de aplicación creados sobre .NET Core.

A diferencia de .NET Framework, .NET Core no se considera un componente de Windows. Por lo tanto, las actualizaciones vienen como paquetes NuGet, no a través de Windows Update. Dado que el tiempo de ejecución de .NET Core está instalado en App-Local y las aplicaciones se actualizan a través del administrador de paquetes, las aplicaciones se pueden asociar con una versión de .NET Core en particular y actualizarse individualmente.

.NET Standard Cada implementación del marco administrado tiene su propio conjunto de bibliotecas de clase base. La biblioteca de clases base (BCL) contiene clases como manejo de excepciones, cadenas, XML, E / S, redes y colecciones.

.NET Standard es una especificación para implementar BCL. Dado que se requiere una implementación de .NET para seguir este estándar, los desarrolladores de aplicaciones no tendrán que preocuparse por las diferentes versiones de BCL para cada implementación de marco administrado.

Las bibliotecas de clases de Framework (FCL) como WPF, WCF y ASP.NET no forman parte de BCL y, por lo tanto, no se incluyen en .NET Standard.

La relación entre .NET Standard y una implementación de .NET es la misma que entre la especificación HTML y un navegador. El segundo es una implementación del primero.

Por lo tanto, .NET Framework, Xamarin y .NET Core implementan .NET Standard para BCL en su marco administrado. Dado que la industria de la computación continuará introduciendo nuevo hardware y sistemas operativos, habrá nuevos marcos administrados para .NET. Este estándar permite a los desarrolladores de aplicaciones saber que habrá un conjunto consistente de API en las que pueden confiar.

Cada versión de .NET tiene una versión asociada de .NET Standard.

Al proporcionar API consistentes, la migración de aplicaciones a diferentes implementaciones administradas, así como la provisión de herramientas, es más fácil.

.NET Standard se define como un solo paquete NuGet porque todas las implementaciones de .NET son necesarias para admitirlo. Las herramientas se vuelven más fáciles porque las herramientas tienen un conjunto consistente de API para usar en una versión determinada. También puede crear un único proyecto de biblioteca para varias implementaciones de .NET.

También puede crear contenedores estándar de .NET para API específicas de la plataforma.

-1

Cada marco tiene su biblioteca de clases.

  • Biblioteca de clases base para .Net Framework.
  • Biblioteca central para .Net core.
  • Biblioteca de clases mono para Xamarin.

Microsoft ha decidido llevar todas estas bibliotecas de clases a una sola biblioteca que se puede implementar en todos los marcos. Para ello, desarrollaron el estándar .Net.

Microsoft ha decidido crear un marco unificado. .Net 5 es un marco unificado de .Net core y .Net Framework. En .Net 6, fusionan Xamarin bajo el proyecto .Net MAUI con .Net también.

.Net Framework, .Net Core, Xamarin están unificados en un solo Framework .Net 6, por lo que no es necesario el estándar .Net. El objetivo del estándar .Net era tener una biblioteca que funcione en todos los marcos. Ahora todos los marcos están fusionados en .Net 6.