Breaking change in default imports when core compiler is used from netfx builds

[jjonescz]

Core compiler is now used by default even in netfx builds. That results in a breaking change in behavior due to this:

roslyn/src/Compilers/Shared/BuildClient.cs

Lines 86 to 94 in 7cf6390

	/// <summary>
	/// Returns the directory that contains mscorlib, or null when running on CoreCLR.
	/// </summary>
	public static string? GetSystemSdkDirectory()
	{
	return RuntimeHostInfo.IsCoreClrRuntime
	? null
	: RuntimeEnvironment.GetRuntimeDirectory();
	}

Workaround: set msbuild property RoslynCompilerType=FrameworkPackage.

[jaredpar]

Think the best approach for getting the old behavior here is to change this condition to whether we're running on .NET Core or .NET Framework MSBuild. That would give us 100% parity with the old behavior.

At the same time though, this flag is meaningless when we are targeting .NET Core. It actually gives us negative behavior because it allows to compile against implementation assemblies where we should be compiling against reference assemblies. My initial thought is that we should use GetRuntimeDirectory when both are true:

1. Running on MSBuild Framework
2. $(TargetFramework) is empty

That is a value though that we'd need to calculate at the msbuild task level and feed through to the compiler. The logic within the compiler, when it's invoked outside of msbuild, should remain as it is today (mostly cause I can't see any other alternatives).

[jaredpar]

@rainersigwald, @baronfel, @JoeRobich

[jjonescz]

To clarify, I imagine this would be implemented such that the Csc build task passes some /sdkpath:{RuntimeDirectory} option if it's the netfx->netcore bridge task. Does that sound right?

And I'm not sure why we should consider TargetFramework.

1. The Csc task doesn't know about TargetFramework anyway, we would need to add a parameter to it but that causes problems as we learnt recently.
2. This break would be reproducible even if using framework msbuild against a netcore project (where TargetFramework would be set) so adding such condition would not fix the break there.

[rainersigwald]

Yeah I'm also not seeing the TargetFramework connection. It's a bit unfortunate that this would always use the impl assemblies from Framework, but that's what the Framework compiler has always done, and I guess it's fine if you're just referencing string or whatever.

[jaredpar]

We'll be using the impl assemblies for .NET Framework when building .NET core applications.