System.Runtime.Loader should be netcoreapp1.0, not netstandard1.5

[gulbanana]

It's actually a coreclr-specific API and doesn't work on other .net standard 1.5 platforms like net462 and xamarin.

[weshaggard]

@ericstj?

[ericstj]

@gulbanana the package would fail to install correctly if you install it into a desktop project. I suspect the problem you're pointing out is that if you're just building a netstandard library nothing stops you from using this, correct?

The problem here is that most of these packages that have framework-specific implementations were relying on gaurdrails to block them from being used in netstandard libraries, but the gaurdrails check was removed from NuGet without a replacement.

We made all the packages declare their API as NETStandard so that we wouldn't be blocking other frameworks from implementing this API. In other words, someone could implement this for Desktop or Xamarin in a seperate package and packages which depend on it would just start working without forcing us to ship a new version of the package (and gaurdrails would start passing).

Given that gaurdrails was cut and not likely to come back and folks aren't keen on individual package refs & install state to represent compatibility I think we can take this suggestion.

Essentially for any package that doesn't implement all of the frameworks for a particular netstandard version, don't expose a netstandard ref. We may need to be selective if that breaks existing scenarios (eg: ref.emit).

[gulbanana]

you're right, I was building a netstandard library and wanted a way to know i shouldn't use the package. for now, I've made my own library dual-tfm net452/netcoreapp1.0 and used separate implementations of assembly loading.

that history makes sense and I think the new plan is good. it will be nice to reach a world where library authors can support unanticipated future platforms by using safe-for-everything deps.

[ericstj]

FWIW if you wanted "extra protection" you could add supports clauses to your project.json. This will evaluate all your dependencies for the platforms you list. This is the "gaurdrails" feature I talked about, it's not enabled by default.

In the project.json you'd add the following:

  "supports": {
    "netcoreapp1.0.app" : {},
    "net462.app": {}
  },

I'd still like to keep this issue open to evaluate what we want to do for these packages.

[joperezr]

@ericstj is this something we still want to pursue for 1.2.0 release? If so, we need to get a list of the packages we need to switch to runnable TFMs instead of netstandard ref so that somebody can pick this one up.

[danmoseley]

@ericstj can you answer the above. trying to figure out whether 2.0,future, or close this.

[danmoseley]

cc @joperezr

[ericstj]

We no longer produce a package for this so in that sense it is fixed.

[gulbanana]

Is S.R.L. available in netstandard 2's unified package, then? Sounds good, as long as it actually works on all platforms.

[mellinoe]

No, it's only available in the .NET Core package, and only works on CoreCLR.

[gulbanana]

Also fine!