views:

336

answers:

3

When adding a reference to a web application project in VS (2008 in this case), the "hintpath" in the csproj file is being created as a relative reference. Is there a way (using the GUI, not manually editing the file) to make this an absolute reference (i.e. C:\Temp\DllName.dll)?

The issue I am running into is when seperate build machines have a different working directories for the project. When the reference is relative, and the referenced dll is not within the project working directory, the relative reference may not point to the same location on both machines.

A: 

I would like to help but why is this necessary? I have never had to do this ever - since vs.net beta 2003. I think there is another deeper question here.

If you must you can try the Reference Path page in the project properties

Gary
Usually, this happens when someone else loads a project into a solution, in a different path depth than it was originally created.
hova
I have led .net teams for years and you will go #@#$ nuts this way. This is the first thing I fix. Get everyone to bite the bullet and organize your solution project and references an cut off anyone's {beep} who {beep}s with it.
Gary
Well, that explains why you have never had to do this then.
hova
You have to ask yourself why are hard coded references not easily accomplished? MS did us a favor! Because in a team environment you use source control. It is more important that everything work relatively below your workspace folder. Then everyone can have different paths to their specific workspace. It is really not that hard. Continuous integration and deployment are also much easier as well.
Gary
+1  A: 

Try right clicking the properties of the project, and then going to Reference Paths, and adding the hard coded paths there.

hova
I did this, but it doesn't appear to actually change anything in the .csproj file. So, wouldn't this have to be added on each dev/build machine?
Jeremy
A: 

By default, Visual Studio uses relative references when the reference is initially added, because it assumes that the reference is to a file elsewhere in your working copy.

This used to drive me nuts, but I solved it in three different ways:

  1. By keeping my source code on my D: drive, meaning that DLLs referenced on the C: drive could not be stored with relative paths.
  2. By persuading the powers-that-be to use a single image/script for all of the developer workstations. Now that they're all the same, the files are all in the same place on the C: drive.
  3. By realising that you can add folders to the AssemblyFolders registry key, meaning that you no longer have to use paths of any kind to reference known assemblies.
Roger Lipscombe