Don't use ResolvedPath metadata on ReferencePath

[sbomer]

This fixes #286, introduced by dotnet/sdk#1857, which removes some metadata from this ItemGroup.

I tested this on a simple project. @nguerrera, can you confirm whether the ReferencePath ItemGroup should contain the correct path to any resolved assemblies in general? If not, which item metadata could we use instead?

[nguerrera]

@nguerrera, can you confirm whether the ReferencePath ItemGroup should contain the correct path to any resolved assemblies in general

Depends what you mean by resolved assemblies. Historically, ReferencePath is all of the assemblies that will be passed to the (C#/VB/F#) compiler. Is that what you want in this context? I ask because a linker would need to link runtime assemblies in general, which may not be in ReferencePath.

As of recently, the compiler actually gets @(ReferencePathWithRefAssemblies), not @(ReferencePath). So for the case of CompileUsingReferencesAssemblies=true (dotnet/msbuild#2039), @(ReferencePath) will have implementation assemblies of user projects and @(ReferencePathWithRefAssemblies) will have the reference assemblies for user projects. However, for nuget packages with lib/ and ref/ split, @(ReferencePath) will have reference assemblies and only @(ReferenceCopyLocalPaths) will have implementation assemblies.

(Aside: It strikes me just now that perhaps we should think about changing nuget case to use the same mechanism (or some generalization thereof) as CompileUsingReferenceAssemblies. Nuget case came before CompileUsingReferenceAssemblies, which explains the divergence. I haven't thought it through fully, there might be an avenue for fixing issues like missing binding redirect generation for assemblies excluded from compilation, etc.)

cc @ericstj @rainersigwald

[nguerrera]

and only @(ReferenceCopyLocalPaths) will have implementation assemblies

Correcting myself, this isn't true for CopyLocalLockFileAssemblies=false (.NET Core default).

Anyhow, I'm guessing that you must already have had to deal with all of this to link runtime assemblies from NuGet, and ReferencePath is indeed what you need in this context. But I didn't want to just answer yes because the ref/lib split case is very often missed.

[sbomer]

Closing this since this is fixed with the 3.0 SDK integration.