Need to merge runtime.json's into the Targets packages

[ericstj]

Currently we have many packages including runtime.json's to represent x-plat implementations.

This causes a problem when any of those packages is not in the compile graph since DNX/NuGet will not merge runtime.json's that aren't in the compile graph.

For many of our packages that are considered "part of the platform" we already have a common runtime.json that is meant to serve as defining the implementation package for a specific platform: the Microsoft.NETCore.Targets.* packages. For any package already listed in these packages we should merge in the runtime.json that came from that specific package. This will ensure that the runtime.json content is in the compile graph.

This is not a complete solution. Some of our packages are not "part of the platform" and third party packages are not either. For these we need the nuget feature: NuGet/Home#1660.

Once that feature exists we should also adopt it in all of our packages in addition to the runtime.json since it supports a more dynamic mapping. EG: I can update a single package that has new platform specific dependencies/shape without updating the entire platform.

/cc @chcosta

[joshfree]

This is fixed in 23502.00 and newer builds https://www.myget.org/gallery/dotnet-core-rel

[guardrex]

@ericstj @anurse

Having ...

"System.Net.Security": "4.0.0-beta-*",
"Microsoft.NETCore.Platforms": "1.0.1-beta-*",

... was working and providing System.Net.Security in my beta8 dnxcore50 proj (it was pulling down -23409 earlier when we discussed it in https://github.com/dotnet/corefx/issues/3927), but it's broken again. Merely having that combo in dependencies doesn't work. I've had to go back to ...

"System.Net.Security": "4.0.0-beta-23405",

It looks like the fix on this will be for rc1. Should I just stick with -23405 until I move to rc1?

[ericstj]

Using the latest packages on an older beta8 dnx is not going to work for a few reasons

1. The latest packages rely on packaging features added post-beta8
2. DNX includes a fixed copy of some of our implementation assemblies. Even though the newer packages may specify a dependency on a newer version of these implementation assemblies from packages, you'll still be running on the older version. This can result in any number of problems at runtime: missing type, missing member, differing behavior, missing p-invokes, etc.

I know 2. is a problem for this package in particular because it has undergone a ton of development in this milestone where it has required new members from our native binaries that are inside DNX\bin. This library itself however is not part of DNX\bin so you end up running in torn state.

[guardrex]

@ericstj Ok, thanks. I'm going to stick with -23405 until I go to rc.

[guardrex]

@ericstj Question on Microsoft.NETCore.Targets.DNXCore ... just noticed this package. My apps are all dnxcore50 framework only. Can I/should I use this one in place of Microsoft.NETCore.Platforms?