Hi.
I think current MSBuild project xml lack some flexibility when storing assembly references. This may be the result of toolchain evolution, not the design flaw, but its what it is now:
When project referencing assembly - it stores corresponding data in Reference ItemGroup like this
<Reference Include="Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\packages\Newtonsoft.Json.6.0.8\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>
And it has single HintPath node which uses absolute or relative path. The problem with relative path that it's being calculated once when reference is added and can't cater for later structure changes.
E.g. if we are using nuget - default packages path is defined as $(SolutionDir)\Packages. And if project is located just one folder below say First.sln file - final reference path is expanded like ..\packages\<path to nuget dll> which is ok.
Unless you want to include same project into to another, Second.sln, file which is located above or below First.sln folder. In this case project reference becomes incorrect - default packages folder for Second.sln doesn't match with expanded ..\packages\ anymore.
Thus we have a dependency on the $(SolutionDir) value which is not re-evaluated during build.
I can see few potential fixes for this:
$(NugetPackagesPath)\Newtonsoft.Json.6.0.8\lib\net45\Newtonsoft.Json.dll - this will be re-evaluated on each build and can enable certain scenarios for build servers either.Happy to hear your opinion on the described issue
Team Triage: Improving this area isn't currently on the MSBuild engine roadmap. NuGet changes may address this in the future.
2.5 years later, still not dealt with
1000 days later, still not dealt with
Most helpful comment
2.5 years later, still not dealt with
1000 days later, still not dealt with