2

So our build system and source control system is from Perforce, which is a piece of poopers.

We want to change reference to dlls in the project to some other location, for example, current reference might be C:\blah\debug\blah.dll, we want to change it d:\codeinjected\blah\debug\blah.dll

But we don't want to do this is the VStudio project file, because that is also our MSBuild build lab file, so is there a way to make an addin that can do it on the fly, without actually changing the references?

halivingston
  • 3,727
  • 4
  • 29
  • 42

1 Answers1

1

It sounds like you situationally want to change the location of reference DLL's for a Visual Studio project. The easiest way to do this is to add condional constructs into the MsBuild file itself. 

<Reference Condition="$(OnDevMachine)">
  ...
</Reference>
<Reference Condition="$(OnLabMachine)">
  ...
</Reference>

Another option is to have a common msbuild file for all of your projects. In that particular project you can create a conditionally defined value pointing to the reference directory and have every leaf project reference that variable. It will be less code and possibly more amenable to your build guy. 

<PropertyGroup>
  <ReferenceDir Condition="$(OnDevMachine) == 'true'">Some\Dev\Path</ReferenceDir> 
  <ReferenceDir Condition="$(OnLabMachine) == 'true'">Some\Lab\Path</ReferenceDir>
</PropertyGroup>
JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • Except, I can't bloat the csproj files, our build master suggested to ask on SO for other alternatives than this. Any ideas on how to potentially fake it while in the IDE? – halivingston Jan 08 '12 at 03:54
  • The IDE uses the MsBuild files; this is the correct way to do what you want. I don't know why you/your "build master" deride it as "bloating" the files. It does no such thing. Surely your build system can handle a couple of additional lines. – Cody Gray - on strike Jan 08 '12 at 04:15
  • @user986697 I added another possibility that will perhaps be more amenable to your build guy. However i do feel like alterting the build file structure is the right approach here. This is a build problem and should be solved by the build system. I've been on **many** teams which have taken similar approaches. – JaredPar Jan 08 '12 at 17:23