[WIP - Do not merge] Generate Microsoft.NETCore.Runtime.CoreCLR nuget packages

[gkhanna79]

They are generated for Windows, Linux (Centos, Debian, Ubuntu) and OSX.

SOS is placed next to CoreCLR.

@weshaggard @ericstj PTAL. Also, the following are outstanding:

1. Determine how to insert reference to the APISets nupkg
2. Unify this package with Razzle build so that we have a single nuget package generation

[gkhanna79]

Fixes https://github.com/dotnet/coreclr/issues/3015

[gkhanna79]

@dotnet-bot test this please

[krytarowski]

Shell portability issue. This will fail on NetBSD. == is extension in test(1).

[krytarowski]

I forgot that build.sh enforces gnu bash. Do with my notes whatever you like. Thanks for your patch.

Hopefully there will be added NetBSD platform soon too.

[krytarowski]

..but if you like, converting it to /bin/sh and reducing dependency shouldn't be too difficult.

[ericstj]

I think @ellismg is changing this to rhel.

[gkhanna79]

@ellismg Let me know if rhel is the final naming for centos scenario and I will do the needful.

[ellismg]

Yes, please change __DistroName to rhel. It should be fine to have both centos and rhel builds produce packages with the rhel.7 RID for now.

[ellismg]

At some point, we are going to need to extend these checks to bring in the version of the distro so we don't produce packages with an Ubuntu 14.04 RID when building on Ubuntu 15.10. I wouldn't let that block progress here, but we should file an issue so we know to follow up. I think @ericstj has a similar issue in CoreFX around building the "wrong" packages on Linux because today the build doesn't know about which Linux distro it is targeting and so we just produce all the packages.

[gkhanna79]

I think that is fine. We should have this function/capability be present in buildtools package (or akin). For me, I picked up the logic from https://github.com/dotnet/cli/blob/a7f438f85d5a68c8f4c61bb422c39bbf3c1e1822/scripts/common/_rid.sh.

Needless to say, there shouldnt be multiple copies for such a function.

[ellismg]

I agree we should unify this. I oepend dotnet/buildtools#437 to track.

[davidfowl]

Why aren't mscorlib and coreclr co-located in the package itself?

[ericstj]

mscorlib needs to satisfy guardrails so it must be in lib. Ref side is design time facade in portable compatibility pack (for mscorlib-based PCLs).

[davidfowl]

I think we need it in both places then. It's impossible to use CoreCLR from a package because mscorlib needs to be next to coreclr.dll. We're hitting this right now with the CLI and the only workaround would be to xcopy those 2 dlls into the output path or edit the package cache in place (eek!)

[ericstj]

I see, how about both in lib? Lib+ native would bin clash. Alternatively we could have the il in lib and ni in native.

[davidfowl]

I see, how about both in lib? Lib+ native would bin clash. Alternatively we could have the il in lib and ni in native.

That could work, but now thinking about it, package size might me an issue? Also we'll end up with both the ni and non ni in the output folder. Bin clashing seems better here.

Another question to @gkhanna79 @schellap @jkotas would be to understand why coreclr and mscorlib need to be side by side in the same folder? Maybe the code can be changed so that it looks in the usual places (like the TPA list) for assemblies...

[gkhanna79]

Alternatively we could have the il in lib and ni in native.

@ericstj @davidfowl We dont need IL version of mscorlib since the NI can satisfy that requirement.

mscorlib needs to satisfy guardrails so it must be in lib.

@ericstj Can you please elaborate on this?

[jkotas]

Why do we need both mscorlib.ni.dll and mscorlib.dll? mscorlib.ni.dll should be enough. If the .ni.dll suffix is a problem, we can rename it mscorlib.ni.dll to mscorlib.dll.

[davidfowl]

mscorlib needs to satisfy guardrails so it must be in lib. Ref side is design time facade in portable compatibility pack (for mscorlib-based PCLs).

Can't this be in another package? Why would that be in the runtime package...

[ellismg]

I have a vested interest in the raw mscorlib.dll being available from packages somehow. The code-coverage runs we do in CoreFX will not instrument code from mscorlib.ni.dll, last I checked, so being able to restore a version of the run-time that didn't use native images would be great. It may also be helpful in bootstrapping scenarios (e.g. do we know that mscorlib.ni.dll compiled for Linux would work on FreeBSD/OSX/Some Other Linux Distro?)

[ellismg]

This is out of date with what we have in CoreFX for the RID graph, but if you do what @ericstj says above, you can delete this file.

[ericstj]

@jkotas ni.dll isn't a problem, I was just suggesting something that would permit an entry in both lib and native without a binclash.

@gkhanna79 gaurdrails is the feature in nuget that caluculates if a package is compatible with a given framework/RID pair. It looks at the compile entries in the compile graph and the runtime entries in the runtime graph and makes sure that every compile assembly has a matching runtime assembly. If not it means the package is not compatible with targeted runtime/framework. https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Commands/CompatilibityChecker.cs

Can't this be in another package? Why would that be in the runtime package...

The design-time facade is in another package. On net-native (where we don't have mscorlib) there is a corresponding runtime facade. On coreclr we can't have a runtime facade since it has a real mscorlib. The right thing to do here is have the real mscorlib satisfy the gaurdrails check for the design-time facade because that accurately models what actually happens at runtime: a v1 PCL with an mscorlib reference will bind directly to the real mscorlib when running on coreclr. We can't have any other package with this mscorlib because it would either a) clash with this one or b) not clash but be unused IL.

I did a quick check to see if native would satisfy the compat check and it does not. We could move the entire runtime to the lib folder which would work on windows, but not on unix since lib is filtered to just dll.

[ellismg]

When you change this stuff to rhel, please use rhel.7 as the prefix in the RID. See dotnet/corefx@f71d339 for the changes I made for RHEL support in CoreFX.

[gkhanna79]

Fixed.

[davidfowl]

We could have mscorlib.dll IL in a seperate package that's only brought in directly, or in the case of the PCL compatibility check to satisfy gaurdrails. That's likely better anyhow since I think the mscorlib IL pivot isn't as granular as the runtime (distro + arch). Thoughts?

That sounds much better.

[ericstj]

Yeah, I'm inclined to do that. It means we'd only en up downloading the IL in the case of someone using the PCL v1 compat package (a legacy package) or directly referencing it.

[gkhanna79]

@ellismg @ericstj Incorporated PR feedback. For now, I am packaging both mscorlib.dll (in lib) and mscorlib.ni.dll (next to CoreCLR).

I would like to keep this change moving unblocked, so we should figure out how to remove the IL version of mscorlib and get nuget railguard verification still working.

[gkhanna79]

@mmitche Since we now build mscorlib.dll on the respective OS, as part of this change, I have updated the CI groovy script to no longer build non-Windows mscorlib on Windows. PTAL and let me know if anything else is missing/needs to be done.

[gkhanna79]

why coreclr and mscorlib need to be side by side in the same folder? Maybe the code can be changed so that it looks in the usual places (like the TPA list) for assemblies

Theoretically, CoreCLR and mscorlib could be in different folders and made to work. However, the semantic to keep in mind is that, logically, CoreCLR and mscorlib.dll are a single artifact - they just happen to live in managed and native implementations. Mscorlib is the managed part of the runtime though, due to historical reasons, has had non-runtime specific FX code as well.

To maintain the above semantic, it is important that they are packaged together and deployed together, which has a good side-effect of them being next to each other and also results in Mscorlib's path on TPA to be derived from CoreCLR's path.

[gkhanna79]

I see that CentOS CI invoked the build as " + ./build.sh skipmscorlib verbose checked x64" from a custom shell script. @mmitche Is this CI specific shell script or generated in the repo? I need to have it no longer pass skipmscorlib argument for non-Windows platforms.

[gkhanna79]

@mmitche The Windows build failed due to the following:

d:\j\workspace\dotnet_coreclr\debug_windows_nt_bld_prtest>build.cmd debug x64 linuxmscorlib

This is inspite of my changes in netci.groovy. Is there any other place I need to make change to?

[ellismg]

The groovy changes in a PR don't impact that PR. You should do @dotnet-bot test ci please to ask Jenkins to generate the new job definitions, inspect them for correctness and then merge the PR. The changes will be picked up for future jobs.

[ellismg]

(Note that because of how the groovy stuff works, it's best to pull the changes into a separate PR and stage your changes so that you can update the CI definitions after updating the product to ensure you don't break the world)

[jkotas]

if anything else is missing/needs to be done.

Once this goes through, we should also fix corefx CI to start using mscorlib native image on Unix (right now, the script is deleting it - https://github.com/dotnet/corefx/blob/master/run-test.sh#L169 - it was workaround for Windows native image getting picked up on Unix by accident).

[gkhanna79]

@piotrpMSFT @Sridhar-MS What is the latest version of CLI that works on CentOS? Does restore operation work on CentOS?

[ellismg]

I would really like to keep the ability to cross compile mscorlib for other OS's on Windows. We support this in CoreFX for the rest of the managed code and it's very useful for both bootstrapping and local development.

[gkhanna79]

@dotnet-bot test Ubuntu x64 Checked Build and Test