How can I make the SourcePath property of a file in a Visual Studio Setup and Deployment project (Windows Installer) relative rather than absolute?

Question

I've got a relatively simple project that is under source control (svn), and I wanted to create an installer. I know that I could (should) use WiX, but as I'm new to creating installers I thought it'd be easier to just use the built-in Visual Studio (2010) Setup and Deployment Wizard.

Unfortunately, it seems that files including external (non-project maintained) documentation, configuration files, and "Content" files are added with absolute paths. This, of course, is suboptimal. I searched the web, but found only the same question, without an answer. Another stackoverflow user seems to have asked a similar question, but the only answer, which suggests ClickOnce, seems off-base (I'd like to have an MSI that I distribute not a web-based installation).

Does anyone know how (or whether) this can be fixed?

Answer 1

With VS2005, sometimes the paths stored in the vdproj file were absolutes, and sometimes relatives. In my case, it seemed to be related to whether the files were accessed via the canonical path or not. Here's a concrete example:

Source is on C:\Views\builddir, open solution C:\Views\builddir\solution.sln and add files from C:\Views\builddir\.. and VS2005 would add relative paths into the vdproj file. However, if you map that builddir to a letter drive, for example, make a subst from C:\Views\builddir to s:, open the solution via S:\solution.sln, and then add files by navigating to S:\.., VS2005 would insert absolute paths into the vdproj files. Whether VS2005 displayed paths as absolutes or relatives had no relation to what it stored in the vdproj files.

So, it may well be that the problem comes down to what path you're using to open that solution.. opening \\server\shareddir\solution.sln might get different behavior than mapping \\server\shareddir to W: and opening w:\solution.sln.

You can always add the files, then use a text editor (e.g. notepad) to change the absolute paths in the vdproj file to relative ones. You'll be fine until you change that project again.

MS doesn't seem to really fix minor bugs like this so much as rewrite the code to introduce an entirely different set of bugs, so VS2010 might still act this way.

FYI, why would one want to map an absolute path to your builddir? It was a holdover from the bad old days when VS didn't do anything correct with relative paths.