14

We're forever having this problem, we have a number of solutions and an adjacent /Components/ folder. All the DLLs we want to reference are in this folder. Some of them we've built from source to use a specific version number that only existins in the Components binary but when a user on a different machine gets-latest of everything from TFS and so has the exact on disk structure Visual Studio STILL changes the references to ones that are installed in Program Files, the GAC or elsewhere.

Have tried manually editing the proj file to include HintPath, e.g.

<Reference Include="Foo, Version=5.5.5.5, Culture=neutral, processorArchitecture=MSIL">
    <SpecificVersion>False</SpecificVersion>
    <HintPath>..\Components\Foo.dll</HintPath>
</Reference>

to no avail. How do we FORCE visual studio to respect this path?

  • Are you sure you don't have `ReferencePath` specified in .user/targets file? It takes precedence over HintPath. See more at http://stackoverflow.com/a/2733113/105350. Also, what do you mean by "no avail"? VS removes `HintPath` from the file or what? – andreister Jul 31 '13 at 11:41

3 Answers3

6

Setting "SpecificVersion" to true, in addition to specifying the "hintPath" seemed like a solution because it "prevents visual studio from using multiple target rules for assembly resolution".

However, once foo.dll is unavailable (while building or loading a project) Visual Studio magic kicks in and changes the assembly target path to the nearest 'matching' assembly.

After this point, it doesn't matter whether the original foo.dll is restored to its location (at the target pathname) or even CHANGED! - Visual studio still refers to its newly found match. This is very undesirable.

Possible solutions:

  1. Strong Name foo.dll, but then foo.dll may only reference other strong named assemblies (often undesirable).

  2. Customize assembly resolution by registering for an event in the parent application. This allows you to define exactly where to find the target assembly at runtime - but this seems like far too much effort to resolve this simple problem.

My work around for this problem (easily) was to set LOCAL COPY to FALSE, and add a post build step to the project, which manually copies the target assembly to the target bin folder. The bad part about this is the amount of duplication (and decoupling) created between the post-build step and the References configuration of the project.

Please Microsoft - add an option to the Reference property page that that will prioritize the hintPath (which we explicitly specify) over the surprise magic path... or at the very least, throw a warning/error if the two differ from one another!

Fortmann
  • 433
  • 6
  • 20
1

We have the same setup - we reference 3rd party assemblies (and some of our own) in a separate folder, and hints in a .csproj file work just fine for us.

Visual Studio will first try to find the dll in the HintPath and only if it doesn't find it, then it looks further - the binaries next to the executing assembly, solution folder, or the GAC. Also, remember that the Reference Paths tab in the project properties is treated the same way as HintPath, and that the listed order of folder hints matters.

If this is still bugging you, maybe you should think about raising your own local NuGet server (which supposedly isn't all that complicated), from which the assemblies will get collected automatically on solution load. It's a bit of an overkill, but it also handles the issues with multiple versions of dll's being used across different solutions. We still haven't done this so I can't recommend it first-hand, but it's on our to-do list.

veljkoz
  • 8,384
  • 8
  • 55
  • 91
1

The hintpath can sometimes be a bit difficult. Visual Studio isn't as intelligent as we need it to be sometimes and that's why we can edit the csproj file in XML. The way to do this is by doing the following:

1.) Right-Click the project in solution explorer and select "Unload project". // This will make the project inactive in solution explorer.

2.) Right-Click the project again, while it is inactive, and select "Edit YourProject.ext" where ext is either vbproj or csproj. This will open an XML editor in Visual studio. //If you need to search within the file, you can press Ctrl-F, but remember you will have to adjust the "Look in:" to be "Current document", otherwise it will not be searched.

3.) When viewing/editing has been completed and changes saved, you close the XML file, Right-Click the project again and select "Reload project".

I paraphrased these steps that I found from here: http://wiki.visualwebgui.com/pages/index.php/Visual_Studio_HintPath#Viewing_or_editing_the_project_file

I hope this helps, it has helped me.

Eric Milliot-Martinez
  • 4,076
  • 3
  • 23
  • 28