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

Question

В настоящее время, пытаясь узнать о стандарте .NET Platform, я обнаружил, что я совершенно смущен идеей «разных платформ».

Я постараюсь сделать свою мысль понятной. То, что я сейчас сейчас рассматриваю в .NET Framework, заключается в том, что .NET, грубо говоря, составлен из CLR, BCL и поддерживающего программного обеспечения для загрузки CLR и обеспечения интерфейса между виртуальной машиной и базовой ОС.

Поэтому, когда мы кодируем .NET Framework, мы действительно нацеливаем некоторую версию фреймворка, потому что типы, которые мы используем из BCL, поставляются с каркасом и поэтому зависят от конкретной версии.

Теперь, .NET Core совсем другой, как я понял. Это не все упаковано вместе. У нас есть CoreCLR, который представляет собой легкую виртуальную машину для запуска IL, CoreFX, которые являются библиотеками, правильно организованными как пакеты NuGet, и у нас был до сих пор DNX/DNVM/DNU, который обеспечивал поддержку таких вещей, как загрузка CoreCLR и взаимодействие с ОПЕРАЦИОННЫЕ СИСТЕМЫ.

В любом случае, несмотря на то, что, если мы установим фреймворк на Windows 7, Windows 8 или Windows 10, то код в отношении рамки.

Теперь на .NET стандартной платформы спецификации мы видим следующее определение:

Platform - например .NET Framework 4.5, .NET Framework 4.6, Windows Phone 8.1, MonoTouch, UWP и т.д.

Также мы видим, что после того, как список платформ, который включает в себя

• .NET Framework 2.0 - 4.6
• Windows 8
• Windows Phone 8,1
• Silverlight 4, 5
• DNX на .NET Framework 4.5.1 - 4,6
• DNX на .NET Core 5.0

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

Но здесь у нас есть эти платформы, которые включают платформу .NET, как только одна из многих платформ. У нас есть, например, Windows 8, но подождите минуту, запуск .NET в Windows 8 - это не то же самое, что работать с .NET на любой другой ОС? Почему он отделен от платформы .NET Framework 2.0 - 4.6?

У нас также есть DNX в качестве конкретной платформы. Это заставляет меня задуматься: платформа - это «вспомогательный материал», связанный с загрузкой виртуальной машины и предоставлением интерфейса с ОС? Или на платформе есть виртуальная машина?

В любом случае, как видно, я довольно смущен. Каковы эти платформы и как это относится к моему нынешнему пониманию .NET Framework? Кроме того, почему .NET Framework 2.0 - 4.6 описывается отдельно? Это не все описано здесь в некоторой версии .NET Framework, если только .NET Core?

Answer 1

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

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

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

Answer 2

Закодируем против сруба.

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

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

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

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

Answer 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, который обозначает "Переносные библиотеки классов". Используя только небольшое общее подмножество методов/сборок в двух или более платформах .NET, можно было бы создать библиотеку, которая могла бы быть включена в проекты, предназначенные для разных фреймворков. Например, профиль 37 PCL означает, что вы хотите, чтобы ваша библиотека могла использоваться в проектах .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