CODEWITHSUNDEEP
c#.netcross-platform.net-standard
Felipe Yañez
Felipe Yañez

Reputation: 28

Net standard package

I've been researching a whole day about .NET Standard and its integration with multiple frameworks; I think i get it all, but only one question wanders in my mind and its related to the package inclusion.

For example, i am targeting the net standard 1.6 and when i look at the assemblies list in visual studio 2017 i can see: "System.Reflection (4.3.0)". Meaning that i have support for that version of the assembly, but the API specs for the net standard version says that it doesn't support for example "System.Reflection.Emit.ILGeneration".

So what happens if i add the package ILGeneration 4.3.0; According to the package i need support for:

System.Reflection (>= 4.3.0)
System.Reflection.Primitives (>= 4.3.0)
System.Runtime (>= 4.3.0)

Which i have according to the assemblies list, so my questions are:

Thanks in advance.

Upvotes: 0

Views: 425

Answers (1)

Martin Ullrich
Martin Ullrich

Reputation: 100581

The big difference here is that there are some APIs that are in / part of .NET Standard and some packages that are built on top of it.

In .NET Standard < 2.0, "the standard" is defined by the closure of packages that the NETStandard.Library package brings in. System.Reflection.Emit.ILGeneration is then considered to be outside of the standard but should work for most platforms supporting the .NET Standard because it is built on top of it - for ILGeneration in particular, this may not be exactly true since it is tied closely to the underlying runtimes. But the point is that packages built on top of the standard can offer api but choose to throw exceptions when a particular platform doesn't support a feature.

Instead of referencing NETStandard.Library, packages built from CoreFX reference the individual packages to avoid some chicken-and-egg problem (NETStandard.Library and Microsoft.NETCore.App are mostly just collection of their packages). Some other 3rd party libraries do this as well, but this setup is discouraged for new projects since some fixes come in via updates to NETStandard.Library.

A weird side-effect of Microsoft.NETCore.App being composed of packages is that there are a few packages built for .NET Standard 1.6 are bringing in implementations rather than just defining "a contract".

For .NET Core 2.0 and .NET Standard 2.0, this setup changes a bit since the two packages NETStandard.Library and Microsoft.NETCore.App are no longer "meta-packages", but flat packages containing a bunch of dlls (and even native assets for self-contained applications). Also a library built for netstandard2.0 will contain no package references by default when publishing - the API of .NET Standard is considered to be brought in by the platform.

With this in mind, lets look at your questions:

  1. The reasons for IL generation not being part of the standard is most likely the AOT compilation limitations. This includes Xamarin iOS but may also apply to .NET Native and CoreRT. Since not all platforms are required to implement the API, this is considered an "extension to the standard" so it may not work on all platforms, even if they support .NET Standard 1.6

  2. Only if this other project needs to run on a platform that does not support the APIs in question. The limits introduces by using this package applies transitively to all projects referencing it.

  3. Only your features :) The .NET SDK doesn't support Xamarin target frameworks by default but by using the MSBuild.Sdk.Extras NuGet package you can create a library that multi-targets .NET Standard and Xamarin iOS.

Upvotes: 1

Related Questions