Nuget hintpath issue

Topics: General
Oct 26, 2012 at 2:28 AM

We use latest nuget in VS2010/2012 for referencing dependencies such as Castle Windsor, Rhinomocks, AutoMapper, etc..

After nuget does its magic, the cs project file for project Acme might have a new reference item like this.

<HintPath>..\..\..\..\..\Services\Windows\BatchCleanup\packages\Castle.Core.3.1.0\lib\net40-client\Castle.Core.dll</HintPath>

This works great for when project Acme is built in context of Solution Foo (where the Nuget dependency was originally established) but when project Acme is built in context of Solution Bar this breaks (we have package restore enabled for each solution).  Because we share projects across numerous solutions, Nuget dependencies are a source of pain.  To make this work across all solutions, we change the hint path so it is relative to solution dir macro.

<HintPath>$(SolutionDir)\packages\Castle.Core.3.1.0\lib\net40-client\Castle.Core.dll</HintPath>

This works but requires alot of extra effort.  Is there a better way to handle this scenario?

 

 

 

Oct 26, 2012 at 4:26 AM

We have recently accepted a pull request from a contributor which does exactly this, i.e. using the $(SolutionDir) macro for the HintPath. Unfortunately, it won't be available until NuGet 2.3. For the time being, I guess you will have to modify them manually.

Oct 26, 2012 at 4:57 AM

In addition to that, you can also try setting the "repositorypath" in your Nuget.config file to install all packages in a common folder (say in the root of your source tree). This way the projects across all the solutions would pick up the packages from the same location. 

Nov 13, 2012 at 8:52 PM

Can you provide the issue number or a reference to the pull request that will be included in 2.3?

Nov 13, 2012 at 8:54 PM

http://nuget.codeplex.com/SourceControl/network/forks/vermeeca/nuget/contribution/3479

Nov 13, 2012 at 8:54 PM

The pull request has already been approved.

Jan 10, 2013 at 8:01 AM

Glad to hear this will be fixed soon, we're also manually adding $(SolutionDir) to the HintPath in all our projects.

Jan 10, 2013 at 10:43 AM

Sorry to break the bad news but we have reverted this change because we found a bug with using the $(SolutionDir) in the HintPath. It is that it breaks if you build just the project on the command line, in which case $(SolutionDir) is not available.

Feb 26, 2013 at 5:37 AM
I think this feature should work for projects in solutions, which already have packages Auto-restore feature on. Such proj-files already have a line like this
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == 'Undefined'">....\</SolutionDir>
and also an import
<Import Project="$(SolutionDir).nuget\nuget.targets" />
So such project has $(SolutionDir) variable available.
Moreover such project could'n be built separately from command line without appropriate environment (.nuget folder with nuget.exe, target-file).

As for me, this feature is mandatory. We have a solution with 180 projects which are basis for another solutions with derived projects and that's one hell of the issue to change all manually.
We consider now using a fork of nuget with patch by vermeeca, because its' very important for us.
Apr 9, 2013 at 2:44 PM
Any update on this feature? Is it going to be in a new version? We have the same problem (solution with many projects) and manually changing all projects would not be a good solution!
Apr 9, 2013 at 11:51 PM
We've received a pull request from vermeeca to implement this feature. Unfortunately, we won't be able to include it in the upcoming 2.5, due to shortage of time.

If you need it now, you can build a custom version of nuget out of vermeeca's fork here. https://nuget.codeplex.com/SourceControl/network/forks/vermeeca/nuget/contribution/4444
Jun 14, 2013 at 9:06 PM
I would also like this enhancement. Please could you confirm which version this will be included in?
Jun 25, 2013 at 5:12 PM
Because this is such a big change that has largest testing impact, we need some time to evaluate it. Hence I can't confirm which version this will be included in, but rest assure that we'll try to do it ASAP. Meanwhile, you can grab the fork from vermeeca, compile it locally and use it for your purpose.
Jul 26, 2013 at 10:25 PM
dotnetjunky wrote:
We've received a pull request from vermeeca to implement this feature. Unfortunately, we won't be able to include it in the upcoming 2.5, due to shortage of time.

If you need it now, you can build a custom version of nuget out of vermeeca's fork here. https://nuget.codeplex.com/SourceControl/network/forks/vermeeca/nuget/contribution/4444
As part of this, planned feature, how tough would it be to have the "hint path" be pulled from the nuget.config?

What I was thinking was something along the lines of:
<config>
<add key="hintPath" value="<<value to sub in>>" /> <!-- value="$(SolutionDir)\packages" or "C:\lib\nuget-packages" -->
</config>

which would result in the hint path becoming something along the lines of:
<HintPath>$(SolutionDir)\packages\Castle.Core.3.1.0\lib\net40-client\Castle.Core.dll</HintPath>
<HintPath>C:\lib\nuget-packages\packages\Castle.Core.3.1.0\lib\net40-client\Castle.Core.dll</HintPath>

if this key doesn't exist, then it would default to the relative path behavior it has now?
Jul 22, 2014 at 8:03 AM
Hi,

Are there any news concerning this issue? I have 2.8 installed.

Thanks