c# - generate - ¿Cuáles son las plataformas en.NET Platform Standard?

params comments c# (3)

Ahora esto me confunde completamente. Siempre pensé: codificamos contra .NET Framework y el framework es el framework sin importar qué.

No, en realidad existen marcos o plataformas de .NET plurales como quiera llamarlos. Antes de .NET Standard, solía apuntar a un solo marco (tal vez el completo, actualmente en la versión 4.6.3, si desarrolla aplicaciones web o servicios de Windows). Las DLL que apuntan a un marco no son compatibles con otra. IE una DLL desarrollada para .NET Framework completo no puede ejecutarse en Windows Phone 8.1.

Estos marcos en realidad implementan un conjunto bastante pequeño de bibliotecas, pero también bibliotecas específicas para tratar con la plataforma a la que están destinados. Las bibliotecas de IE para administrar un servidor web alojado en IIS en el marco completo de .NET o funciones para tratar con un teléfono móvil en el marco de Windows Phone 8.1.

Antes de .NET Standard era el PCL

Aunque hubo una solución alternativa, llamada PCL que significa "bibliotecas de clases portátiles". Al usar solo el pequeño subconjunto común de métodos / ensamblajes en dos o más marcos .NET, uno podría desarrollar una biblioteca que podría incluirse en proyectos dirigidos a diferentes marcos. Por ejemplo, el perfil PCL 37 significa que desea que su biblioteca se pueda usar en proyectos .NET Framework 4, Silverlight 5 y Windows 8.

Mire esto para obtener una lista de los perfiles PCL y sus compatibilidades (no sé si es exhaustiva): http://danrigby.com/2014/05/14/supported-pcl-profiles-xamarin-for-visual-studio-2/

Ahora, ¿qué pasa con .NET Standard?

El objetivo de .NET Standard es simplificar esto y deshacerse de los PCL. A grandes rasgos, .NET Standard define un contrato (un conjunto de clases y métodos), que será implementado por todos los frameworks .NET. Si desarrolla una biblioteca orientada a .NET Standard, está seguro de que puede ejecutarse en todos los marcos .NET. Es la idea / objetivo básico detrás de esto (aunque es un poco más sutil).

Eche un vistazo a esto para la compatibilidad exacta: https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/#user-content-whats-new-in-net-standard-20

Si observa la tabla de compatibilidad, verá que una biblioteca dirigida a .NET Standard 1.6 se puede usar tal como está (no es necesario recompilarla) en las aplicaciones .NET Framework 4.6.3 y .NET Core 1.0.

En otras palabras, podemos decir que .NET Framework 4.6.3 y .NET Core 1.0 implementan el contrato .NET Standard 1.6 : sus clases y métodos.

Si también desea que su DLL sea utilizable en un proyecto de Windows Phone 8.1, tendrá que apuntar a .NET Standard 1.2, que ofrece menos funciones que .NET Standard 1.6 (no, por ejemplo, System.Net.Sockets).

Consulte aquí una lista de los espacios de nombres disponibles en cada versión de .NET Standard https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#user-content-list-of-net-corefx-apis-and-their-associated-net-platform-standard-version

Actualmente, tratando de aprender sobre .NET Platform Standard, me he sentido bastante confundido acerca de la idea de "plataformas diferentes".

Trataré de aclarar mi punto. Lo que ahora cuento con .NET Framework es que .NET se compone aproximadamente de CLR, BCL y software de soporte para iniciar CLR y proporcionar la interfaz entre la máquina virtual y el sistema operativo subyacente.

Entonces, cuando codificamos utilizando .NET Framework, nos dirigimos a alguna versión del marco porque los tipos que usamos de BCL vienen con el marco y, por lo tanto, dependen de la versión específica.

Ahora, .NET Core es bastante diferente como lo entendí. No todo está empaquetado de esa manera. Tenemos el CoreCLR, que es una máquina virtual liviana para ejecutar el IL, el CoreFX, que son las bibliotecas adecuadamente organizadas como paquetes de NuGet y hasta ahora teníamos el DNX / DNVM / DNU que proporcionaba el material de soporte como el arranque del CoreCLR y la interfaz con el OS

De todos modos, a pesar de que si instalamos el marco en Windows 7, Windows 8 o Windows 10, codificamos contra el marco .

Ahora, en la especificación estándar de la plataforma .NET, vemos la siguiente definición:

Plataforma: por ejemplo, .NET Framework 4.5, .NET Framework 4.6, Windows Phone 8.1, MonoTouch, UWP, etc.

También vemos después una lista de plataformas, que incluye

.NET Framework 2.0 - 4.6
Windows 8
Windows Phone 8.1
Silverlight 4, 5
DNX en .NET Framework 4.5.1 - 4.6
DNX en .NET Core 5.0

Ahora esto me confunde completamente. Siempre pensé: codificamos contra .NET Framework y el framework es el framework sin importar qué.

Pero aquí tenemos estas plataformas que incluyen el marco .NET como una de las muchas plataformas . Tenemos, por ejemplo, Windows 8, pero espere un minuto. ¿Ejecutar .NET en Windows 8 no es lo mismo que ejecutar .NET en cualquier otro sistema operativo? ¿Por qué está separado de la plataforma .NET Framework 2.0 - 4.6?

También tenemos DNX como plataforma específica. Esto me hace pensar: ¿la plataforma es esa "compatibilidad" relacionada con el arranque de la máquina virtual y la interfaz con el sistema operativo? ¿O la plataforma incluye la Máquina Virtual?

De todos modos, como se puede ver estoy bastante confundido. ¿Cuáles son esas plataformas y cómo se relaciona esto con mi comprensión actual de .NET Framework? Además, ¿por qué .NET Framework 2.0 - 4.6 se describe por separado? ¿No está todo lo descrito aquí alguna versión de .NET Framework a menos que .NET Core?

Codificamos contra el framework.

Bueno, seguro que lo eres. Cuando manipules cadenas en tu código, siempre usarás System.String. Y (casi) siempre se comporta de la misma manera con los mismos métodos y propiedades.

Pero mostrar la cadena tiene detalles de implementación que realmente no puedes ignorar:

Si desea mostrarlo en un terminal Unix en Linux u OSX, entonces necesita apuntar a Mono o CoreCLR, las implementaciones de framework que pueden ejecutarse en dichos sistemas operativos.
Si desea mostrarlo en una aplicación de la Tienda Windows (también conocida como WinRT, también conocida como Windows 8, también conocida como UWP), en realidad es un HSTRING debajo del capó, un detalle muy bien escondido del que no tiene que preocuparse. Pero requiere un gadget de UI, como Windows.UI.Xaml.Controls.TextBlock, una clase que es altamente específica para WinRT
Si desea mostrarlo en un navegador, entonces debe apuntar a ASP.NET o Silverlight, hosts de marco optimizados para ejecutarse en un servidor web o como complemento para un navegador.
Si desea mostrarlo en un dispositivo que funciona con una pequeña batería de iones de litio, como un teléfono, inevitablemente tendrá que lidiar con una versión de la plataforma que se optimizó para usar la menor cantidad de energía posible. Eso afecta el código que tiene que escribir, hay una gran diferencia entre el código que quema 100 vatios y el código que mantiene viva una pequeña batería durante 8 horas. Nada que pueda ver directamente, más allá de la necesidad de usar async / await mucho, pero ciertamente algo que afectó mucho el tiempo de ejecución. Se requiere apuntar a Xamarin o WinRT.
Si desea mostrarlo en cualquier sistema operativo, entonces necesita apuntar a una versión de marco que no use el tipo de trucos que usa .NET en Windows para que un EXE ejecute la máquina virtual CLR. Eso requiere dnx.exe, al igual que usaría java.exe o python.exe para programas escritos en Java o Python.

Sería encantador si esos detalles de implementación no importaran. Pero no de la forma en que funciona en la práctica, ya que .NET prolifera y está disponible en más y más dispositivos y sistemas operativos, inevitablemente también se vuelve más complicado. Elija sus objetivos previstos temprano, es importante.

Existen muchos Frameworks (.NET Framework, WinRT, UWP, Silverlight, .NET Core, Windows Phone, Mono, Micro Framework y el antiguo Compact Framework) no solo el .NET Framework.

La nueva forma es programar contra un estándar de plataforma que admita uno o más de estos marcos. El estándar de la plataforma define una API que coincide con uno o más marcos. Esto significa que si su aplicación es compatible con el estándar de plataforma 1.1, es probable que admita casi todos los marcos. El estándar de plataforma 1.4 admitirá .NET Framework 4.6.xy solo .NET Core

Eche un vistazo a este documento: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md