DNX does not select a runtime or resolve runtime assets

[ericstj]

Packages can have runtime specific assets. Currently our .NET packages define a set of runtime IDs with a heirarchy that are used by our packages. This works fine for UWP, PCL, and Desktop where the MSBuild task uses an active RID when resolving runtime assets, but not on DNX.

This is going to become even more important as we use the RID more in the upcoming release to distinguish between linux and windows assets.

[analogrelay]

Going to capture some of the results of our previous design discussions on this:

1. DNX will have a built-in "runtime.json" that will define DNX-specific runtime IDs. For example dnx-win8-x64, dnx-linux-x64, etc. These will inherit from base RIDs to join in the general RID ecosystem
2. At runtime, it's pretty clear what RID we are using. OS Version detection might get a bit tricky, but at the very least we can know the OS type (win/linux/darwin) and bitness
3. Restore time is the tricky part. In NuGet3 we require that project.json contains a runtimes section, and we will likely support that in DNX as well. However, we're not sure we want to require it. The question then becomes, what do we do when there is no runtimes section? Do we assume it contains all the dnx-* RIDs? Maybe we do have to require it, but we still need to think on that a bit.
4. Much like we do for CLR quirking versions, we should probably provide ways for dnu and dnx to take in a runtime to force DNX to select that runtime (if it is compatible with the project).

[danroth27]

@Eilon @lodejard We need to figure out what to do here for beta7

[analogrelay]

After chatting with @ericstj, @davidfowl and @Eilon we decided we can move this to beta8

[analogrelay]

Ok, the final design I'm going with is as follows:

1. Every DNX knows it's RID components: (Operating System Version, Architecture).
2. At runtime, the DNX looks up the section in the targets of the lock file for it's specific RID. There must be an exact match, meaning the project must be restored for the correct operating system(s)
3. Each DNU has a set of RIDs it will restore for by default. These consist of the combination of the currently-running OS version and all known architectures. For example, on Windows 10: win10-x86, win10-x64, win10-arm. On Windows 7, win7-x86, win7-x64. On Linux: linux-x86, linux-x64, linux-arm, etc.
4. If a project contains a runtimes section, we will always use that to produce a set of RIDs to restore for.
5. If a project does not contain a runtimes section, we will restore for the default set for that particular DNU (see 3 above). This would include Class Libraries, because we didn't want to force the use of runtimes on an application (since in DNX any class library can be an application as well, there is no distinction)
6. dnu restore would have a --runtime flag that would override all other values and provide the complete set of runtimes to restore for.
7. When embedding a runtime during dnu publish we will identify the RIDs specified by that runtime and restore for them as well. For example if you are on windows and run dnu publish --runtime dnx-coreclr-darwin-x64.1.0.0-..., we will restore for darwin-x64 as part of the publish.

/cc @davidfowl @lodejard This sounds like the vague conversations we had, but we never landed on a concrete design here so let me know if I'm way off base.

[ericstj]

/cc @nguerrera @ellismg @stephentoub
Our packages will need at least distro, version, and arch components in our RID. Based on this and 1& 2 above it looks to me like you're going to have to produce separate DNXs per distro:version:arch, even if nothing else in DNX is distro specific. Perhaps you should consider some sort of OS query to determine this instead of tying it to the package?

[analogrelay]

We can probably do something there. We already make uname calls for other purposes.

Even better would be if the CoreCLR can expose enough data for us to synthesize the RID :)

[ericstj]

Not sure that'd help, it's a chicken/egg how do you know which CoreCLR implementation assemblies to use until you have the RID to evaluate the package?

[analogrelay]

These decisions will all be happening after booting the CoreCLR/DNX, they are only for packages used by projects. DNX has to have the binaries necessary for booting itself in the DNX runtime folder. That may mean we need distro-specific DNXes if you have distro-specific assemblies for those packages. It would be good to sync up on that as quickly as possible.

Will the CoreCLR be distro-specific as well?

[nguerrera]

Yes, the CoreCLR will be distro-specific.

[ericstj]

Just a thought here: why can't you pre-resolve a lock file for the DNX runtime when building DNX? I imagine your native piece that bootstraps DNX has enough smarts to look at a JSON file to determine paths to dependencies instead of assuming they'll all be in a single folder. The native piece can then make some calls into native APIs to determine the RID and thus the target section in the lock file to use.

It seems pretty heavy handed to fork DNX per distro when the only thing that's likely to be different are some native shims on the bottom of stack.

[analogrelay]

Well, in that case how would we even ship libcoreclr.so? Would we ship all the distros together in one big package by folder? ubuntu\libcoreclr.so, etc.?

[analogrelay]

/cc @moozzyk @DamianEdwards @davidfowl

[analogrelay]

The DNX has to be self-contained for enough to boot itself. We don't want it to be dependent upon external packages at boot time. Applications can use packages, but the runtime itself is self-contained. So, if the CoreCLR (and the packages necessary to boot DNX) are going to be distro-specific, we would likely have to be distro-specific as well.

[bricelam]

Native library loading doesn't appear to be implemented. Is that tracked in a separate issue? (Reopening until I hear otherwise)

[moozzyk]

#402?

[bricelam]

Yep