35

Is it possible to use environmental variables in the build output path in VS 2008 (et al)/ I'm trying to find a solution where several developers on my team using both Windows XP & 7 and all with different Windows logons, can all modify projects and common referenced dll's (source held on Source Safe) and not screw up the relative paths? I've tried such things as %userprofile% and $(userprofile).

I've looked into post build events but these do not really seem to provide an anawer to my problem. Sadly I'm not in the position to use 3rd party add-ons either as these will be non-commercial and it's nearly impossible to get authorization for any licences for them.

(Similar unanswered question at Output path for build in visual studio 2010)

Community
  • 1
  • 1
PaulTee
  • 351
  • 1
  • 3
  • 3

5 Answers5

38

You need to open the csproj file in a text editor and manually enter your environment variables in the OutputPath section. Visual Studio escapes the '$', '(' and ')' when you try to do this from the IDE.

PhilMY
  • 2,621
  • 21
  • 29
2

I've used the subst command to accomplish this sort of thing in the past. Essentially all project references define paths in relation to a known drive letter like R:\MyProject\outputs.

Then every developer can map the R: drive (or whatever) to the folder structure particular to their environment. As long as the folder structure beneath the mapped drive is the same, the location of that mapped folder can vary between machines, builds, and users.

This works well as developers can then set up their environment with a simple batch file and easily switch between branches, projects etc and relative pathing within the projects is not broken.

dkackman
  • 15,179
  • 13
  • 69
  • 123
1

PaulTee, Is it a longshot to ask you try directory replication? Like Dropbox/Synctoy and other tools that invokes a file-copy from choosen location to the expected shared location?

In your situation, I would love to use the built-in environment variables. Probably there are a way to make it work, but until then i would go for such a solution. I would also have in mind that different users compiling to same directory, would make conflicts with both file versions and file locks (used by other user).

Independent
  • 2,924
  • 7
  • 29
  • 45
  • I will have to state explicitly that SyncToy is a Free Microsoft tool, http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c26efa36-98e0-4ee9-a7c5-98d0592d8c52 which also has a API at http://www.microsoft.com/downloads/en/details.aspx?FamilyID=89adbb1e-53ff-41b5-ba17-8e43a2e66254&displaylang=en to develope for own purpose, like this. – Independent Apr 01 '11 at 16:27
  • I shall give that a look - ta – PaulTee Apr 07 '11 at 14:23
1

If you don't mind the extra copies, you could add post-build event that copies the project outputs to a commonly-agreed location for shared dlls, and everyone uses a non-relative reference to that location. It would still, though, require standardization of that target location, so maybe it is not what you are looking for. (example below would allow for drive letter independence at least)

copy $(TargetPath) \dependencies

JeffSahol
  • 971
  • 8
  • 19
  • Post-build events scare me at the mo - having enough 'fun' getting used to C#, .NET, Visual Studio, and SourceSafe for starters! Thanks though. – PaulTee Apr 07 '11 at 14:25
0

While I don't quite understand what you're asking for, it sounds like symlinked directories will help -- you can configure the solution to output to some folder that will be symlinked to arbitrary locations on each individual box.

http://en.wikipedia.org/wiki/NTFS_symbolic_link

ghost edit - mklink is apparently new in 7, but older versions still support it (Russinovich to the rescue once again):

http://technet.microsoft.com/en-us/sysinternals/bb896768

wrmsr
  • 86
  • 1
  • 3
  • That could be an option - I've never tried it in XP, but have done so in W7 and we're all due to go W7 at some point anyway - ta. – PaulTee Apr 07 '11 at 14:26