MSBuild cannot resolve simple-named dependent assemblies

[ericstj]

Steps to reproduce

From a task call Type.GetType() passing a simple name to an assembly which has not been loaded.

See attached project.
msbuildRepro.zip

You can run the net46 version of the sample using desktop msbuild and see that it succeeds:

C:\Users\ericstj\source\msbuildRepro\task\bin\Debug\net46>msbuild /nologo /v:m
lib.MyPlugin

Run the netcoreapp2.0 version of sample using dotnet msbuild and see that it fails:

C:\Users\ericstj\source\msbuildRepro\task\bin\Debug\netcoreapp2.0>dotnet msbuild /nologo /v:m
C:\Users\ericstj\source\msbuildRepro\task\bin\Debug\netcoreapp2.0\test.csproj(6,5): error : Could not load lib.MyPlugin,lib

Expected behavior

Successfully load the simple-named assembly.

Actual behavior

Fails to load the simple-named assembly.

The bug is here: https://github.com/Microsoft/msbuild/blob/7b4c71a46611f5f03c8d5a796ef267aa8af2ae49/src/Shared/CoreCLRAssemblyLoader.cs#L126

In this case the referenced assembly name passed in will be null (since the string didn't contain a version), but the assemblyName returned by AssemblyLoadContext will have a version (since the assembly itself has a version) so this comparison will fail. The simple fix is to change this to

if (assemblyName.Version != null && candidateAssemblyName.Version != assemblyName.Version)

I was able to test a workaround by passing the assembly version to my sample (lib.MyPlugin,lib,Version=1.0.0.0) which is possible here in the contrived case but won't be possible for all folks.

I think to match the CoreCLR loader behavior you might even want to candidate assembly versions that are higher than the referenced version, but that's another issue.

/cc @erozenfeld

Environment data

msbuild /version output:
15.4.8.50001
dotnet msbuild /version output:
15.5.153.27799

If applicable, version of the tool that invokes MSBuild (Visual Studio, dotnet CLI, etc):
15.5.0-preview-007044