Move the netcoreapp2.0 runtime library into the build folder

[NTaylorMullen]

This way a users application can't actually call into ViewCompilation code.

@Eilon this should be done for RTM

[pranavkm]

Might have to check this one - if you have a lib\net451, but no lib\netcoreapp2.0, you might not be able to install the package in a netcoreapp targeting project. That said, there's no API exposed by the assembly and it's not meant to be deployed PrivateAssets="true", so there's not a lot of risk of application code calling in to it.

[Eilon]

With the new PTF vs. ATF thing I don't know what the behavior would be.

[NTaylorMullen]

With the new PTF vs. ATF thing

What's PTF vs. ATF?

[Eilon]

PackageTargetFallback vs. AssetTargetFallback.

[Eilon]

Details here: https://github.com/NuGet/Home/wiki/Enable-.NET-Core-2.0-projects-to-work-with-.NET-Framework-4.6.1-compatible-packages

[Eilon]

Not saying it's necessarily related, but it might be relevant.

[natemcmaster]

Btw, same is true of the .NET Framework assembly. These are currently packed into runtimes/win-{x64, x86}/lib/, which means NuGet treats this as available assemblies. Would be better to put all these console tools in a non-asset folder. Our other tooling packages put these into tools/ or toolsassets/ to ensure NuGet ignores them.

[NTaylorMullen]

Today we do this because we rely on the CLI to auto-generate binding redirect files for those guys. We could manually create binding redirects (and pack them) that would work with most apps to move those bits around.

[natemcmaster]

The binding redirects can't be packed. You have to generate those based on the dependencies of the project.

FWIW - it's more complicated, but you could "borrow" the binding redirects generated for the app, or use AppDomains to better manage assembly resolution.

[Eilon]

We need to talk to @DamianEdwards about some aspects of this because it seems like we're having to work around too many sharp edges in the system.