Fix #1435 - calculation of ResolvedPath for project references

[BrunoJuchli]

See #479 and #1435 for error description and analysis of the problem. In short:

The old implementation combined the relative <ProjectReference Include="..." /> path with the directory of the ProjectAssetFile.
Corrected this to combine the relative project reference with the current's project path.

Questions:

• Is it actually the desired outcome that ResolvedPath points to the csproj file? Or should it point to the output directory of that project?
• Is ProjectPath always passed in as full path? (otherwise it needs to be enclosed by a Path.GetFullPath)

[nguerrera]

@natidea

[nguerrera]

The code before the change does look wrong. I'm trying to understand why this wasn't reported sooner. The repro steps in #1435 don't seem out of the ordinary. @dsplaisted @livarcocc

[natidea]

@nguerrera this was being tracked with #479
Is this incorrect metadata being used anywhere, or is this usage something custom for the reported project?

[nguerrera]

@natidea #1435 says the build is failing due to this.

@BrunoJuchli Do you have anything custom reading this ResolvedPath ?

[nguerrera]

Is #1435 actually an instance of #922? Is there a project.json project involved?

[BrunoJuchli]

@nguerrera In my case there's no project.json involved.
The solutions contains classic *.csproj + "modern" (VS2017,..) .csproj. And some csproj target .net full framework and others netstandard - if that's of any relevance.

This pertains a direct-reference, not a transitive one. The csproj of the project being built contains a <ProjectReference Include='...' /> pointing the the project who's ResolvedPath is calculated incorrectly.

Full source code here: https://github.com/BrunoJuchli/StaticProxy.Fody/tree/7d8b924d90759cb3248803514ba631463358494a/

note: there's two solutions. The relevant is StaticProxy.Fody.sln

And yes, there's something custom reading the resolved path: Fody. The ResolvedPaths is one of the ways its looking for weaver-dll's.

(Not that the reason for bringing this issue up is not to make Fody work, or work any better, it's just how I stumbled upon the issue of there being an invalid path).

I also doubt that this change is correct. As stated in the entry-post I'm unsure whether ResolvedPath pointing to a *.csproj is valid. Shouldn't it point to where the (built) assemblies of of the <ProjectReference...> are located? All the other ResolvedPaths do.

[BrunoJuchli]

@natidea
I concur that #1435 is a duplicate of #479. Sorry for posting the duplicate.
I've updated the issue and this PR accordingly.

@nguerrera
#479 states

The resolved path for project references is not actually used anywhere currently, so this bug does not cause any problems, but should be fixed anyway.

Hence only the consumers will "fail", but a standard build-config without any custom code won't "fail" - it just produces invalid output for external consumers.