1

Closed

Feature Request: Use SolutionDir Macro for HintPath

description

Currently when resolving the path to the referenced DLL in the project file a relative to the project in the solution path is created and placed into the hint path. While this is fine for projects that live in a single solution or within multiple solutions where the solution files are in the same directory, if the project is used in multiple solutions where each solutions directory could be at a different relative path than the others having the "..\packages" style path will cause the reference to be not found in other solutions.

Currently to solve this issue I manually edit the reference's hint path in the project file to look something like this:
<HintPath>$(SolutionDir)\packages\Library\lib\library.dll</HintPath>

I downloaded a copy of the source and looked at attempting to do a string replace but it appears that the object being used to add the reference looks at the above as an invalid URI. After seeing that issue in my attempt to propose a fix I am unsure if what I'm proposing above is correct syntax. I can state that under MSBUILD in VS2012 and TFS2012 it works without issue.
Closed Mar 5, 2013 at 10:04 PM by dotnetjunky
we'll move away from HintPath eventually/

comments

dotnetjunky wrote Mar 1, 2013 at 3:42 PM

We have tried this in the past. However, it has a problem in that if you build a particular project from command line, it doesn't work because in that case the $(SolutionDir) property is not available.

mikejr83 wrote Mar 2, 2013 at 12:57 PM

Is there another way to achieve the same result? This is generally a bigger issue with our packages that are pulled from our local feed server. I had thought of updating those packages so that they utilized a powershell script to alter the hintpath. Obviously this wouldn't work for those packages that were pulled from the offical server.

After I posted this I saw that there may be some issues/features that have received some votes that could offer a similar solution. Would it be plausible to expect some sort of future functionality to mitigate the issue I mentioned in the OP?

tkrafael wrote Mar 4, 2013 at 12:10 PM

Look,
Ive written a package that update project version and create tags in git. I had the same problems, and the workaround is to pass the solutionDir property along other command lines parameters.
I dont know if there are other ways to resolve solution dir using custom mstasks

dotnetjunky wrote Mar 4, 2013 at 4:36 PM

We have a future plan to move away from using <HintPath> for the assembly references and instead resolving them at build time. However, that work is not likely to be done in the next one or two releases.

At this time, you only workaround is to manually update the Hint Path to use $(SolutionDir) yourself, with the caveat that I stated below, which is that building a particular project from command line doesn't work.

Haacked wrote Mar 4, 2013 at 4:58 PM

I run into this all the time. It's very common when you use git submodules for example. Hopefully this scenario gets added to the test suite. :)

dotnetjunky wrote Mar 4, 2013 at 5:50 PM

To be clear, we won't fix the HintPath to use $(SolutionDir).

slolife wrote May 25, 2013 at 8:16 AM

@dotnetjunky, can you share the work item that tracks the changes from using the <HintPath> to something else so we can watch that issue?