Port more compatibility check from NuGet

[muratg]

From @ChengTian on July 27, 2015 18:29

Proposed by @davidfowl :

So we need to port some NuGet codez

https://github.com/NuGet/NuGet3/blob/dev/src/NuGet.Commands/CompatilibityChecker.cs#L76
to solve issues like these:

https://github.com/aspnet/Tooling-Internal/issues/420

Wei actually ported some of this logic already but we need to go further. The sad part is, having some of this logic actually shows that our default class library template won't work with dnx451 (it's broken in more horrible ways).

Can we add this to the beta7 list and treat it as part of the nuget 3 merge?

Copied from original issue: aspnet/dnx#2356

[muratg]

From @ChengTian on July 31, 2015 18:7

@davidfowl @anurse @Eilon

Adding more explanation before I send out PRs to fix a bunch of project.json in our repos:

Compatibility check we are adding here
For some CoreCLR packages (e.g. System.Globalization.4.0.0-beta), they provide dnxcore50-compatible assemblies for compile-time in ref folder (e.g. ref/dotnet/System.Globalization.dll), but they don't provide run-time assemblies for dnxcore50 (e.g. there is no dnxcore50-compatible subfolder in lib folder). This kind of packages are broken because they are incompatible with dnxcore50. We previously silently tolerate those packages but now we want to show errors.

Has this incompatibility issue been fixed in CoreCLR packages
Yes, later version of CoreCLR packages have fixed this issue. For example, although System.Globalization.4.0.0-beta has the compatibility issue, you can get rid of it by bumping up the version to System.Globalization.4.0.10-beta.

Why do we need to react in most repos
Most of our repos actually bring in dnxcore50-incompatible packages as indirect dependencies. For example, if you have System.Console.4.0.0-beta-23123 in your project.json, there is such a dependency chain:
System.Console.4.0.0-beta-23123 -> System.Resources.ResourceManager.4.0.0 -> System.Globalization.4.0.0
and System.Globalization.4.0.0 has the compatibility issue.

After the new compatibility check is merged in, we will see a bunch errors during dnu restore for our repos. So I need to go through most repos and bump up versions of CoreCLR packages.

Why didn't this issue break anything on dnxcore50
Because we are bundling most CoreCLR assemblies in dnx-coreclr runtime bin folder. So although the dependencies of your project don't provide run-time assemblies for dnxcore50, DNX can still load them. That's why our projects can run with dnxcore50 framework although they have dnxcore50-incompatible dependencies.

[muratg]

From @ChengTian on August 13, 2015 18:38

@davidfowl hosted a discussion and they think this is too aggressive. Putting to backlog.

[blackdwarf]

CLI uses proper NuGet code under the hood, so this is not needed anymore.