Msbuild: Allow multiple HintPath nodes for Reference tag or some discovery mechanism for Referenced assemblies

Created on 27 May 2015  路  2Comments  路  Source: dotnet/msbuild

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:

  1. Allow and process multiple HintPath nodes so different solutions can add it's own relative HintPath instead of overwriting other solution's records. This may require changes in VS-Msbuild-Nuget integration.
  2. Make HintPath value 'nuget-aware' for nuget references using predefined property, e.g. $(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.
  3. Enable some kind of 'packages discovery' scenario - like node.js's npm with node_modules (see detailed description here [https://docs.npmjs.com/files/folders#cycles-conflicts-and-folder-parsimony] - so msbuild can walk up by the folder tree to the disk root trying to locate corresponding reference

Happy to hear your opinion on the described issue

Most helpful comment

2.5 years later, still not dealt with

1000 days later, still not dealt with

All 2 comments

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

Was this page helpful?
0 / 5 - 0 ratings