Don't reference netstandard1.x packages

[ViktorHofer]

... when building from source.

This was the only remaining project in roslyn that brought them in.

Contributes to dotnet/source-build#4482

[jjonescz]

@ViktorHofer source build is failing

[ViktorHofer]

@MichalStrehovsky just to double check, src/Scripting/Core/Microsoft.CodeAnalysis.Scripting.csproj shouldn't be referencing the old System.Runtime.Loader package on netstandard2.0 and we should convert AssemblyLoadContext usages to AssemblyLoader when targeting netfx or netstandard, right?

[MichalStrehovsky]

@MichalStrehovsky just to double check, src/Scripting/Core/Microsoft.CodeAnalysis.Scripting.csproj shouldn't be referencing the old System.Runtime.Loader package on netstandard2.0 and we should convert AssemblyLoadContext usages back to AssemblyLoader when targeting netfx or netstandard, right?

Yeah, I don't think the System.Runtime.Loader would do anything good on netfx. Cc @dotnet/appmodel

[ViktorHofer]

What makes this problematic is that Microsoft.CodeAnalysis.Scripting dynamically instantiates either an AssemblyLoadContext or an AssemblyLoader:

roslyn/src/Scripting/Core/Hosting/AssemblyLoader/AssemblyLoaderImpl.cs

Lines 24 to 34 in 7039c4c

	public static AssemblyLoaderImpl Create(InteractiveAssemblyLoader loader)
	{
	if (CoreClrShim.AssemblyLoadContext.Type != null)
	{
	return CreateCoreImpl(loader);
	}
	else
	{
	return new DesktopAssemblyLoaderImpl(loader);
	}
	}

[ViktorHofer]

cc @jaredpar @MichaelSimons @ericstj

The goal is to remove all netstandard1.x package dependencies when building from source (see dotnet/source-build#4482). Roslyn is one of the few remaining repos that bring a netstandard1.x package in. For roslyn it's only a single reference in a single place: System.Runtime.Loader/4.3.0 by Microsoft.CodeAnalysis.Scripting.csproj.

See my comments above. It's hard to get rid off that package as roslyn dynamically instantiates either an ALC or AssemblyLoader.

[jaredpar]

@tmat, @arkalyanms FYI

[ericstj]

For roslyn it's only a single reference in a single place: System.Runtime.Loader/4.3.0 by Microsoft.CodeAnalysis.Scripting.csproj.

As a workaround you could PackageDownload then raw-reference the file. That will avoid pulling the dependencies.

[ViktorHofer]

As a workaround you could PackageDownload then raw-reference the file. That will avoid pulling the dependencies.

Yes, I considered that. The goal here is to remove all netstandard1.x packages. If we keep the System.Runtime.Loader reference then we would need to continue building it in SBRP including its dependencies.

[jaredpar]

The compiler approaches this by representing assembly loading through an interface at the netstandard2.0 layer. Then we have our .NET Framework / Core implementations that are fed through by the host. The actual host is going to target Core or Framework so it can be definitive in what it references.

That model was designed into the compiler very early on though. Not sure if the scripting layer can take this approach or not.