System.Runtime.Loader depends on Net462

[jeffschwMSFT]

Of all the Microsoft.NETCore.App dependencies only 1 requires something higher than Net46 and that package is System.Runtime.Loader. Why?

The reason I ran into this was trying to cross compile a .NET console app between core and net46. To do this I need to target at least 4.6.2, but only for 1 package.

It would be nice to know if that is a hard dependency, a nice to have, or a dependency that could be avoided.

Repo:
dotnet new
vi project.json

{
  "version": "1.0.0-*",
  "compilationOptions": {
    "emitEntryPoint": true
  },
  "dependencies": {
    "Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.0-rc2-3002426"
    }
  },
  "frameworks": {
    "netcoreapp1.0": {},
    "net46": {}
  }
}

dotnet restore
dotnet build

Expected:
dotnet build for .NETFramework,Version=v4.6 succeeds

Actual:
project.json(7,31): error NU1002: The dependency System.Runtime.Loader 4.0.0-rc2-24018 does not support framework .NETFramework,Version=v4.6.

[sergiy-k]

/cc @gkhanna79

[gkhanna79]

@ericstj should comment on this since it was added in dotnet/corefx@6008326#diff-bcca0beb1bc0c8947d8600d02bc07d1a by him. I would suspect this is so since this contract implementation is CoreCLR specific and not supported on the Desktop. But I will let Eric confirm the same.

[ericstj]

/cc @weshaggard
I don't believe Microsoft.NETCore.App has been made to resolve correctly on anything but netcoreapp1.0. https://github.com/dotnet/cli/issues/2924

Even for net462 System.Runtime.Loader isn't supported because, as @gkhanna79 mentions it's a CoreCLR specific API.

[weshaggard]

Correct, currently the goal of Microsoft.NETCore.App is support netcoreapp only. @jeffschwMSFT is there a particular reason you want it to work for other targets? There are a number of TFM's that will not work with it net46 is just one, netcore50 (aka UWP) will also not work with this for example.

[mjsabby]

Can we make this contract be supported on Desktop? Doesn't look too hard. Seems like it would at least solve this problem, and I suspect longer term it'll help libraries that only want to be compiled once and not for each specific TFM if the API area can support them.

[gkhanna79]

@mjsabby There is no goal to support this for Desktop for .NET Core RTM. That said, it can be looked into for Desktop but it will be, at best, an emulation since the loader implementations of the two runtimes are different.

Is your goal only to have a consistent API surface?

[mjsabby]

@gkhanna79 yup, exactly. An emulation so that the API surface is consistent.

[gkhanna79]

@mjsabby Please file a seperate issue, with Future milestone, assigned to me to look into that.

[ericstj]

In the meantime we could add a "platformnotsupported" assembly for 1.0 if folks think that'd help. It'd be an assembly that satisfies the API but throws from every member.

[clairernovotny]

What's the real point here though? Can't the main top-level dependency be NETStandard.Library? That's really what'll cross compile between those TFM's. Then, there'd be a netcoreapp1.0-specific dependency for Microsoft.NETCore.App -- just put it under the right node under frameworks instead of making it apply to the whole project.json.

[gdoron]

@gkhanna79 @onovotny So there's no way a .Net core app could target both Full .Net Framework and Core CLR Framework?
Wasn't that the whole point behind the .NET core?

Am I missing something?
(I really need Full CLR support since there're many libraries that still don't support Core CLR)

Thanks

[gkhanna79]

@gdoron AssemblyLoadContext (within System.Runtime.Loader) is specific to CoreCLR as that is the only runtime that supports the defined semantics. To support this for Desktop, we are tracking that investigation via https://github.com/dotnet/corefx/issues/8526.

[gdoron]

@gkhanna79 And its milestone isn't even 1.0.0 but "future".
How can people use ASP.NET core application while most libraries don't support as of yet Core CLR?

[Tsabo]

I would like to know the answer to @gdoron's question as well.

For me this is very important. I'm an access control developer and have to communicate with a lot of different hardware; alarm panels, video recorders, bio-metrics and many other integration's (the last time I counted was up to 93). Which provide their own SDK's, most just targeting .NET 2.0. The others are low level protocols that I am not about to try and rebuild to target .NET core. Nor am I going to try and build Nuget packages for all of them. That would take an insane amount of time.

Some of those companies are also out of business however the hardware is still out there, deployed and used to this day which means I have to continue to support it (for an example, a nurse call system used at hospitals).

.Net core for all intents and purposes will be completely useless if I cannot reference a class library that is targeting the full framework.

Regards, Jeremy

[gkhanna79]

AssemblyLoadContext was only targeted for .NET Core for the initial release. Our goal is to figure out how to support it for the Desktop FX as well. However, since the load semantics (and design) for Desktop FX are considerably different from .NET Core, it will require some non-trivial amount of work to support the same. This is why the milestone is future as we intend to first investigate what it means to support it from a consistent API surface perspective.

If you wish to use similar semantics on the Desktop, it offers API surface (https://msdn.microsoft.com/en-us/library/system.appdomain.assemblyresolve(v=vs.110).aspx or https://msdn.microsoft.com/en-us/library/system.reflection.assembly.loadfrom(v=vs.110).aspx as exmaples) that can help you get unblocked in the interim.

We understand the API surface is not the same, which is why https://github.com/dotnet/corefx/issues/8526 is marked to be in our BackLog to prioritize investigating it.

.Net core for all intents and purposes will be completely useless if I cannot reference a class library that is targeting the full framework.

Are there other APIs you believe will are not available for Desktop but you would like to see supported there?

[svick]

@gdoron @Tsabo

How can people use ASP.NET core application while most libraries don't support as of yet Core CLR?

ASP.NET Core (and project.json projects in general) runs just fine on .Net Framework. What you need to do is to specify e.g. net461 as the framework (instead of netcoreapp1.0) and remove dependency on Microsoft.NETCore.App.

If you depend on libraries that won't be ported to netstandard, then you won't be able to use CoreCLR or CoreFX, even if this issue is fixed.

[gdoron]

@svick I see, thank you for pointing that out.
So basically it means I'll never going to be able to use CoreCLR and be able to run my applications on non Windows servers.

We already have extremely small libraries pool compared to other frameworks and languages like Node, Ruby, Java, etc.
If I want cross platform support and leverage CoreCLR/fx I'll have to limit myself to even a much much smaller pool.

That kinda killed my enthusiasm regarding .Net core...
Am I right?

[svick]

@gdoron I'm not sure anymore. Apparently, .Net Core will become more compatible with some older projects in the future.

[gdoron]

@svick that is one hell of a vague announcement... 😄
I'm not sure what exactly I read.

Anyway, it seems like I need to stay on Windows and full .Net Framework until things will become clearer.
Thanks.

[AlexGhiondea]

The port of the API to Desktop is tracked by another issue.