Project.json definition dnx451 vs .dotnet ( 4.51)

Boas Enkler picture Boas Enkler · Jul 21, 2015 · Viewed 14.6k times · Source

I've some In asp vnext I can define 3 Types of runtime

  • dnxCore
  • dnx451
  • dotnet

In Project.json it looks like this:

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

and the ui shors this

enter image description here

I assume the following:

dnxCore is the new .net Core Framework.

dotnet is the previous runtime

dnx451: What is different when defining "dotnet" or "dnx451" in the project.json?

Shouldn't both run with the .net execution runtime?

Also depending on which project template i choose ( vNext ClassLib or vNext Console Lib) default contains one or the other.

Answer

Thomas picture Thomas · Aug 7, 2015

Answering your question in a different way: A library should target environments which SDK its requires. If you do not require a SDK use netstandard (or before .NET Core RC2 dotnet).

  • dnxcore50 DNX SDK running on CoreCLR/CoreFx (deprecated, use netcoreapp1.0 instead).
  • dnx451 DNX SDK running on .Net 4.5.1 (Desktop CLR / Full BCL and FCL) (deprecated, use net451 instead).
  • net46 .Net Framework 4.6 SDK running on Desktop CLR / Full BCL and FCL.
  • uap10.0 UWP Windows 10 SDK running on .Net Native/CoreFx.
  • netcoreapp1.0 .NET Core 1.0 SDK running on CoreCLR/CoreFx.
  • netstandard1.5 (RC2, dotnet before) any pure IL code which declares its dependencies (System.Runtime (based) libraries instead of a PCL contracts). Framework dependencies are available for .Net 4.5.x onwards, .NET Core or UWP (System.Runtime based library set in different versions). As with RC2 dotnet is deprecated, use netstandard instead.
  • netstandard2.0 (.NET Core 2.0; ~JUN 2017) any pure IL code which rely solely of the feature set of the netstandard.dll which all platforms (.NET Core, .NET Framework, Xamarin, Mono, Unity3D) have to implement (or throw NotImplementedException). The netstandard2.x is roughly the BCL library of the .NET Framework (without FCL components like WMI, WinForms, WPF, WCF, WWF, ...). By compatability shims, most existing NuGet packages will automatically be netstandard2.0.

So if your library only has some algorithms or is not specific to the platform, use netstandard / dotnet. If any of your dependencies is restricted, this dependency will propagate up to the application (e.g. DNX, UWP, .Net46) which uses it.

I can only highlight like Malachi the article series of Oren. (he just wrote a new one: https://oren.codes/2015/07/29/targeting-net-core/ on the same topic).

ps: dotnet / netstandard is not a concrete runtime it is the abstraction of it. It is a target which in this case does not even specifiy a runtime but instead says: Anything which interprets IL correctly goes. For example dnxcore5 is a target which specify a SDK(DNX) which has a specific runtime (CoreCLR). In this case you can make further assumptions about the runtime behavior (like usage of JIT, availability of x-plat implementation, etc.).

pps: be aware that the dotnet name was transformed into the term netstandard with the upcoming RC2 release. Also the complete DNX SDK was splitted up between the .NET Core and ASP.NET Teams. Therefore, the framework moniker for .NET Core (CoreCLR/CoreFx) is netcoreapp1.0 while 99% of the ASP.NET stack are just libraries with netstandard1.5. The DNX monikers (dnx451 and dnxcore50) where deprecated. When running ASP.NET Core on .NET Framework (instead of .NET Core) use net451. Heavy read for details: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

ppps: Continiously be aware, that the netstandard1.x concept of dependency based contracts was not further developed but changed to one (huge) standard contract (32k APIs; netstandard2.0) which has to be implemented by all platforms including the upcoming .NET Core 2.0. This change has the advantage that most of the existing ecosystem of NuGet package (which refer mscorlib and friends) can be integrated into netstandard2.0 packages by using an intermediate compatibility shims.