views:

38

answers:

3

Hello,

using visual studio we always load and build references to a unit (R:). The problem is that when someone edits any project properties the drive letter is removed from the assembly path and then the build machine can not build the application.

The project file looks like this when created:

<References>
    <AssemblyReference
    RelativePath="R:\ClientContext.dll"
    AssemblyName="ClientContext, Version=8.3.0.0, PublicKeyToken=255e4d2a8e3ef422, processorArchitecture=MSIL"
    MinFrameworkVersion="131072"
    />

And after editing any property:

<References>
    <AssemblyReference
    RelativePath="ClientContext.dll"
    AssemblyName="ClientContext, Version=8.3.0.0, PublicKeyToken=255e4d2a8e3ef422, processorArchitecture=MSIL"
    MinFrameworkVersion="131072"
    />

The project files are vcproj, notsure if this happens in other formats too.

Thanks in advance mates.

+1  A: 

This page may give you some insight, particularly important is the comment about the "RelativePath" setting: "Relative Path - Displays the relative path from the project directory to the referenced assembly." http://msdn.microsoft.com/en-us/library/47w1hdab.aspx

The issue is that it is always going to reset it to be relative to the project.

pstrjds
Yes, I thought about the RelativePath name too and searched for something like AbsolutePath but that attribute does not exists :\
SoMoS
+1  A: 

The IDE really likes relative paths because absolute ones are so brittle. Your build will also break when the R: drive isn't mapped properly. But it is fixable: Project + Properties, Common Properties, Framework and References. Add the R:\ path to the "Additional reference search paths" list.

Hans Passant
Of course the release engineering department takes care of having the R:\ mapped as needed. All the company uses the R:\ drive to deploy compilation results and symbols so it's easy for each one to modify and test an installed application. What I really need is to be able to set the Absolute Path at the project.
SoMoS
Erm, "Additional reference search paths" is a project property. It's what you really need. Have you tried it?
Hans Passant
Mmmm, I thought it was a Visual Studio setting, my bad. I will try this and the HintPath to see what works better. Thanks
SoMoS
Yup, Project + Properties edits project properties :) VS settings are under Tools + Options.
Hans Passant
What's wonderful is that the setting is set to R:\ but even with this if I remove the R:\ from the RelativePath the MSBuild complains about not finding the reference ... :?
SoMoS
+3  A: 

As other people have stated the root issue is that the IDE wants to have relative paths for references. This makes it much easier to share a project / solution between multiple develelopers who can have very different machine setups.

EDIT

As Hans pointed out this question is about C++ which doesn't support the notion of HintPath in the project file. Leaving up in case a C#, VB.Net or F# user stumbles across the question

One way to to work around this is to use the HintPath subnode on Reference. This gives the IDE a hint at where to look when resolving the relative path.

<References> 
    <AssemblyReference 
      RelativePath="ClientContext.dll" 
      AssemblyName="ClientContext, Version=8.3.0.0, PublicKeyToken=255e4d2a8e3ef422, processorArchitecture=MSIL" 
      MinFrameworkVersion="131072">
        <HintPath>R:\ClientContext.dll</HintPath>
    </AssemblyReference>
JaredPar
Good call on the hint path, I knew there was a setting that did something like that but couldn't remember it this morning.
pstrjds
I will try this, thanks.
SoMoS
AS far as I've seen info at the web looks like the HintPath should be R:\ClientContext.dll. Am I right?
SoMoS
@SoMoS yes you're correct. Updated
JaredPar
This is a VC project, it doesn't know beans about HintPath. The project won't load.
Hans Passant
@Hans, missed the VC project part.
JaredPar