forcing references path to use $(solutionDir)packages instaed of ..\..\packages

Topics: General
Mar 24, 2013 at 10:07 AM
Hi,

When I install/upgrade a new package, the default path that the nuget use is a relative path to the packages folder. It is not good for me because some of my project are being loaded into solutions more than once. In one solution the relative path to the packages folder will be ....\packages and in another solution it might be ........\<folder>\<solution filder>\packages.

The best way to solve the above is actually to use $(solutionDir) parameter instead of relative path. I have changed all relative paths to this parameter but found out that whenever a package is being updated with a new version, it changes the path to the relative path :-(

Is there a way to force using the $(solutionDir) instead of the relative path?

Thanks
Gil
Mar 24, 2013 at 12:45 PM
This has just been discussed in http://nuget.codeplex.com/workitem/3094.
Mar 24, 2013 at 1:11 PM
Edited Mar 24, 2013 at 1:11 PM
lextm wrote:
This has just been discussed in http://nuget.codeplex.com/workitem/3094.
Discussed but hadn't been resolved :-(

Moreover, I'm trying to use a single path to all packages of my working copy wiht no success. Whatever I try fails.
I tried to configure the nuget.config. Tried to configure in nuget.tragets and even added -OutputFolder to the install command and -RepositoryPath to the update command.
I have no idea what overrides my configurations :-(
Mar 24, 2013 at 3:09 PM
It is by design if you carefully read, as a result of the current reference system. We will have to suffer some pains till Microsoft makes system level changes.
Mar 25, 2013 at 7:26 PM
lextm is correct. Using the $(solutionDir) in the hint path has the problem in that you can't build your project alone (as opposed to building the entire solution) from the command line.

We're considering a new design where assembly reference is resolved dynamically at build time, which will solve this problem. Stay tuned.

@lextm: How did you post message? Somehow your messages are always duplicated multiple times.
Mar 25, 2013 at 8:46 PM

That'll be great
Thanks
Gil

On 25 Mar 2013 20:26, "dotnetjunky" <notifications@codeplex.com> wrote:

From: dotnetjunky

lextm is correct. Using the $(solutionDir) in the hint path has the problem in that you can't build your project alone (as opposed to building the entire solution) from the command line.

We're considering a new design where assembly reference is resolved dynamically at build time, which will solve this problem. Stay tuned.

@lextm: How did you post message? Somehow your messages are always duplicated multiple times.

Read the full discussion online.

To add a post to this discussion, reply to this email (nuget@discussions.codeplex.com)

To start a new discussion for this project, email nuget@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com

Mar 26, 2013 at 4:15 AM
@dotnetjunky Regarding...
We're considering a new design where assembly reference is resolved
dynamically at build time, which will solve this problem. Stay tuned.
This is important for enterprise scenarios, as dependency management is sometimes best left out of the developers' hands and placed in release engineers' hands. In this case, all releng should have to do is edit packages.config and put in the desired version numbers.

We are planning to add this to ProGet Client Tools soon, as it's something we've had to workaround with some really fun .csproj hacks. There seems to be no easy way to maintain compatability with the way NuGet handles things now (..\packages\mypackage1.2.3), and it seems like it's choosing between ugly (munging .csproj files at install time) and bad (losing compatability with nuget).

We're leaning toward the latter, and just using (..\packages\mypackage) when this behavior is desired.

Do you have any specs/thoughts/etc on how you guys were going to accomplish this?
Mar 26, 2013 at 11:03 AM
dotnetjunky wrote:
lextm is correct. Using the $(solutionDir) in the hint path has the problem in that you can't build your project alone (as opposed to building the entire solution) from the command line.

We're considering a new design where assembly reference is resolved dynamically at build time, which will solve this problem. Stay tuned.
What about adding SolutionDir into the csproj as a property, e.g.:

<SolutionDir Condition=" '$(SolutionDir)' == '' ">..\</SolutionDir>

This way it's there whether building the solution or the csproj standalone.

Would this work as a solution, at least until the new design is in place? If so, I can update an old PR that I had to include this as well.
Mar 26, 2013 at 11:16 AM
@dotnetjunky We have been playing with a similar approach of dynamically loading references as part of an MSBuild target, with removal of hintpaths entirely. This works pretty well, however to make it work nicely would require changes within NuGet (MSBuild target injection, hintpath changes, possible switch to remove transitive assemblies being added). Related discussions:

http://nuget.codeplex.com/discussions/436612
http://nuget.codeplex.com/discussions/433942

with a POC here: https://github.com/BenPhegan/NuGetAutoTransitiveDependencies

Are there any other current discussions around the approach you are looking to take on this? I haven't seen any of the primary team chime in on this at all, and would be interested as to your thoughts.

We have another really dirty hack that does partially work, and involves a subst call to provide a: as a packages location, with a modification to the nuget.config to place a: as the package directory path. This does force an absolute path location (a:\PackageID.Version) as the hintpath, however the location can be mapped anywhere. It does force this on anyone using the code though, so it really only works in corporate environments. Would much prefer a move to some dynamically identified pathing. And yes, I know this is a dirty hack (as stated). :)
Mar 27, 2013 at 9:44 AM
lextm wrote:
This has just been discussed in http://nuget.codeplex.com/workitem/3094.
Disscussed but hadn't been resolved :-(

Moreover, I'm trying to use a single path to all packages of my working copy wiht no success. Whatever I try fails.
I tried to configure the nuget.config. Tried to configure in nuget.tragets and even added -OutputFolder to the install command and -RepositoryPath to the update command.
I have no idea what overrides my configurations :-(
Mar 27, 2013 at 6:23 PM
@vermeeca: You can't always assume that solution root is one level above the current project. They can be at completely different places.
Mar 27, 2013 at 6:29 PM
Edited Mar 27, 2013 at 7:17 PM
dotnetjunky wrote:
@vermeeca: You can't always assume that solution root is one level above the current project. They can be at completely different places.
The property would be created with the realized value of $(SolutionDir) at the time that the reference was added. This would preserve the behavior of the current Nuget for situations where folks are building only a csproj file, would it not?
Mar 27, 2013 at 7:17 PM
That's true.
Mar 18, 2014 at 8:13 PM
Can simply add something like:
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == 'Undefined'">..\PathTo\Solution\at\time\of\install</SolutionDir>

and then use the $(SolutionDir) in all hint paths for references. Agreed, a method of dynamically loading assemblies would be better, but considering it's been a year, and we still haven't seen an action on this front, a more mundane solution would be useful.

At least with this approach, you can move projects around, etc, and your solution still compiles, and if you are building csproj's directly, at least you only have to update the base path in one spot, instead of (10? 20? 30?).