Проект.определение JSON dnx451 против dotnet (4.51)

Question

Проект.определение JSON dnx451 против dotnet (4.51)

У меня есть некоторые В asp vnext я могу определить 3 типа времени выполнения

dnxCore
dnx451
dotnet

В Проект.json это выглядит так:

"frameworks": 
{
    "dotnet": { },
    "dnx451": { },
    "dnxcore50": { }
}^

и ui shors это

Я предполагаю следующее:

dnxCore новый .чистый фреймворк.

dotnet предыдущая время работы

dnx451: Что отличается при определении "dotnet" или "dnx451" в проекте.в JSON?

Не Должны ли оба работать со средой выполнения .net?

также в зависимости от того, какой шаблон проекта Я выбираю ( vNext ClassLib или vNext Console Lib) по умолчанию содержит один или другой.

2 55

.net asp.net-core dnx

2 ответа:

dotnet нацелен на множество совместимости .NET Core 4.6. ссылка

"dotnet это новое ядро .NET для пакетов, которые не имеют каких-либо требований к модели приложения."- ссылка

Итак, по этим определениям dotnet новая среда выполнения, а не предыдущий

7

Thomas · Accepted Answer · 2016-12-23 00:01:21

отвечая на ваш вопрос по-другому: библиотека должна ориентироваться на среды, которые SDK ее требует. Если вам не требуется SDK использовать netstandard (или до .NET Core RC2 dotnet).

dnxcore50 DNX SDK работает на CoreCLR / CoreFx (устаревший используйте ).

dnx451 DNX SDK работает на .Net 4.5.1 (Desktop CLR / Full BCL и FCL) (устаревший используйте net451 вместо).

net46 .Чистая Framework 4.6 SDK работает на настольных CLR / Full BCL и FCL.

uap10.0 UWP Windows 10 SDK работает на .Net Native / CoreFx.

netcoreapp1.0 .NET Core 1.0 SDK работает на CoreCLR / CoreFx.

netstandard1.5 (RC2,dotnet before) любой чистый код IL, который объявляет свои зависимости (System.Библиотеки времени выполнения (на основе) вместо контрактов PCL). Зависимости платформы доступны для .Net 4.5.x и далее, .NET Core или UWP (System.Набор библиотек на основе среды выполнения в различные варианты.) Как и с RC2 dotnet устарело, используйте .

netstandard2.0 (.NET Core 2.0; ~JUN 2017) любой чистый код IL, который полагается исключительно на набор функций netstandard.dll которые все платформы (.NET Core, .NET Framework, Xamarin, Mono, Unity3D) должны реализовать (или бросить NotImplementedException). Элемент netstandard2.x это примерно библиотека BCL платформы .NET Framework (без компонентов FCL, таких как WMI, WinForms, WPF, WCF, WWF,...). По совместимости прокладок, большинство существующих Пакеты NuGet будут автоматически netstandard2.0.

поэтому, если ваша библиотека имеет только некоторые алгоритмы или не специфична для платформы, используйте netstandard/dotnet. Если какая-либо из ваших зависимостей ограничена, эта зависимость будет распространяться до приложения (например, DNX, UWP,. Net46), которое ее использует.

я могу только выделить как Малахия серию статей Орена. (он только что написал новый:https://oren.коды/2015/07/29/таргетинг-net-core/ на же тема.)

ps:dotnet/netstandard не является конкретным временем выполнения это абстракция его. Это цель, которая в этом случае даже не указывает время выполнения, а вместо этого говорит: Все, что правильно интерпретирует IL, идет. Например dnxcore5 является целью, которая определяет SDK (DNX), который имеет определенную среду выполнения (CoreCLR). В этом случае вы можете сделать дальнейшие предположения о поведении среды выполнения (например, использование JIT, доступность реализации x-plat, так далее.).

pps: имейте в виду, что dotnet имя было преобразовано в термин netstandard с предстоящим выпуском RC2. Также полный DNX SDK был разделен между .NET Core и ASP.NET команды. Таким образом, в рамках прозвище .Чистая ядра (CoreCLR/CoreFx) составляет netcoreapp1.0 пока 99% из ASP.NET стек-это просто библиотеки с netstandard1.5. Прозвища DNX (dnx451 и dnxcore50), где осуждается. При запуске ASP.NET ядро на платформе .NET Framework (вместо .NET Core) используйте net451. Тяжелый прочитайте для деталей: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

ppps: постоянно осознавайте, чтоnetstandard1.x концепция контрактов на основе зависимостей не получила дальнейшего развития, но была изменена на один (огромный) стандартный контракт (32k API;netstandard2.0), который должен быть реализован на всех платформах, включая предстоящий .NET Core 2.0. Это изменение имеет то преимущество, что большая часть существующей экосистемы NuGet пакет (который ссылается mscorlib и друзья) могут быть интегрированы в netstandard2.0 пакеты с помощью промежуточных прокладок совместимости.