Каковы платформы в .NET Platform Standard?

Ответ 1

мы кодируем фреймворк.

Хорошо, конечно. Когда вы управляете строками в своем коде, вы всегда будете использовать System.String. И он (почти) всегда ведет себя точно так же с теми же методами и свойствами.

Но отображение строки содержит сведения о реализации, которые вы действительно не можете игнорировать:

• Если вы хотите показать его на терминале Unix в Linux или OSX, вам необходимо настроить Mono или CoreCLR - реализации фреймворка, которые могут выполняться в таких операционных системах.
• Если вы хотите показать его в приложении Windows Store (aka WinRT, aka Windows 8, aka UWP), то на самом деле это HSTRING под капотом, очень хорошо скрытая деталь, о которой вам не о чем беспокоиться. Но для этого требуется гаджет UI, например Windows.UI.Xaml.Controls.TextBlock, класс, который очень специфичен для WinRT
• Если вы хотите показать его в браузере, вам нужно настроить таргетинг на ASP.NET или Silverlight, хосты фреймворков, оптимизированные для работы на веб-сервере или в качестве надстройки для браузера.
• Если вы хотите показать его на устройстве, на котором работает небольшая литий-ионная батарея, например, телефон, то вам неизбежно придется иметь дело с каркасной версией, которая была оптимизирована для использования как можно меньше энергии. Это влияет на код, который вы должны написать, существует огромная разница между кодом, который сжигает 100 Ватт и код, который поддерживает крошечную батарею в течение 8 часов. Ничто из того, что вы можете увидеть прямо, за исключением необходимости использовать async/ожидание много, но, конечно, что-то, что сильно повлияло на время выполнения. Требуется таргетинг на Xamarin или WinRT.
• Если вы хотите показать его в любой операционной системе, вам нужно настроить таргетинг на версию фреймворка, которая не использует трюки, которые .NET использует в Windows, чтобы запустить EXE для виртуальной машины CLR. Для этого требуется dnx.exe, так же как вы используете java.exe или python.exe для программ, написанных на Java или Python.

Было бы прекрасно, если бы эти детали реализации не имели значения. Но не так, как это работает на практике, поскольку .NET распространяется и становится доступным на все больше и больше устройств и операционных систем, он неизбежно также становится более запутанным. Сначала выберите целевые объекты, это важно.

Ответ 2

Существует много рамок (.NET Framework, WinRT, UWP, Silverlight,.NET Core, Windows Phone, Mono, Micro Framework и старая Compact Framework), а не только .NET Framework.

Новый способ - программировать против стандартного платформы, который поддерживает одну или несколько из этих фреймворков. Стандарт платформы определяет API, который соответствует одной или нескольким фреймворкам. Это означает, что если ваше приложение поддерживает стандартную платформу 1.1, вы, вероятно, будете поддерживать почти все фреймворки. Стандарт платформы 1.4 поддерживает только .NET Framework 4.6.x и .NET Core

Посмотрите на этот документ: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

Ответ 3

Теперь это меня смущает полностью. Я всегда, хотя: мы кодируем .NET Framework и фреймворк - это структура независимо от того, что.

Нет, на самом деле существует множество платформ или платформ .NET, которые вы хотели бы назвать. До .NET Standard вы использовали таргетинг на единую структуру (возможно, полную, в настоящее время в версии 4.6.3, при разработке веб-приложений или служб Windows). DLL, ориентированные на структуру, несовместимы с другой. И.Е. DLL, разработанная для полной платформы .NET, не может быть выполнена на телефоне Windows 8.1.

Эти структуры фактически реализуют довольно маленький общий набор librairies, но также и специфические библиотеки для работы с платформой, для которой они предназначены. И.Е. библиотеки для управления веб-сервером, размещенным в IIS, в полной платформе .NET или для работы с мобильным телефоном в каркасе Windows Phone 8.1.

До того, как .NET Standard был PCL

Было, однако, обходное решение, называемое PCL, которое означает "Portable Class Libraries". Используя только небольшое общее подмножество методов/сборок в двух или более платформах .NET, можно было бы создать библиотеку, которая могла бы быть включена в проекты, предназначенные для разных фреймворков. Например, профиль PCL 37 означает, что вы хотите, чтобы ваша библиотека могла использоваться в проектах .NET Framework 4, Silverlight 5 и Windows 8.

Пожалуйста, посмотрите на это список профилей PCL и их совместимости (я не знаю, является ли это исчерпывающим): http://danrigby.com/2014/05/14/supported-pcl-profiles-xamarin-for-visual-studio-2/

Теперь о .NET Standard?

Целью .NET Standard является упрощение этого и избавление от PCL. Пример:.NET Standard определяет контракт (набор классов и методов), который будет реализован всеми платформами .NET. Если вы разрабатываете библиотеку, предназначенную для .NET Standard, вы уверены, что она может работать на всех платформах .NET. Это основная идея/цель, стоящая за ней (хотя она немного более тонкая).

Посмотрите на это для точной совместимости: https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/#user-content-whats-new-in-net-standard-20

Если вы посмотрите на таблицу совместимости, вы увидите, что библиотека, ориентированная на .NET Standard 1.6, может использоваться как есть (нет необходимости перекомпилировать ее) в приложениях .NET Framework 4.6.3 и .NET Core 1.0.

Другими словами, мы можем сказать, что .NET Framework 4.6.3 и .NET Core 1.0 реализуют контракт .NET Standard 1.6: его классы и методы.

Если вы также хотите, чтобы ваша DLL была пригодна для использования в проекте Windows Phone 8.1, вам нужно настроить таргетинг на .NET Standard 1.2, который предлагает меньше функций, чем .NET Standard 1.6 (например, нет System.Net.Sockets).

См. здесь список доступных пространств имен в каждой версии .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