Installer projects in Visual Studio are for creating the Setup.exe and the MSI for installing the other projects in a solution. However, I discovered an oddity that caused havoc with our source control system.
We’re using Subversion (SVN) with the Tortoise SVN client. Subversion works by adding a hidden folder to all the folders in your source controlled project. These folders (called .svn) contain the control files that subversion uses. Mostly, they are hidden though (unless, like me, you set up Windows Explorer to show you everything).
The problem I was having was that after I built my installer project, if I tried to check things into SVN, I got an error saying that I needed to run cleanup. I’d run cleanup, and get the error “Subversion reported an error while doing a cleanup” and then a directory path followed by “is not a working copy directory”. I couldn’t actually fix this problem.
To get around this error, I checked my project out of SVN again, into another directory. In my ‘broken’ folder structure, I found and deleted all of the .svn folders! I then copied all of the current files in that ‘broken’ copy across into my newly checked out copy. Finally, I checked that copy of the folder structure in – and it worked. Phew!
However, if I rebuilt my installer project, it broken the source control again. WTF? I didn’t feel like having to do this ‘check out second copy and overwrite all of it’ thing every time I did a build of the installer, so I started to investigate.
Looking at the error message, I could see that the path that “is not a working directory” is the debug folder of my installer project. I went to that folder and hey! No .svn folders. Where did they go? Eventually, I puzzled it out. When you build a normal project in visual studio, it just overwrites the output in the debug or release directory, but with the installer project, it actually deletes the whole effing directory. Thus, my SVN control files are gone!
To fix, I had to:
1) Exclude the Debug and Release directories of my installer project from SVN. This mean deleting them from the working copy in the repository, checking out a second copy, and doing that overwriting thing to fix the error, as described above. I could then right click and exclude those directories. Hurrah!
2) However, I want my installer’s .exe and .msi files under source control, so I created two directories – Output_Debug and Output_Release
3) I wrote a batch file, and then set up a post build action on my project to run that batch file. My post-build event was just the command "$(ProjectDir)CopyForSourceControl.bat". To set this, to the properties for your installer project, and click on the ‘…’ button to the right of the PostBuildEvent field.
Anyway, the CopyForSourceControl.bat file reads:
cd..
xcopy debug Output_Debug /Y
xcopy release Output_Release /Y
Thus, the debug and release folders themselves are no longer under source control and so won’t break it when you build the installer project. However, when you run that build, a copy of the output will be put into a directory which is under source control. Hurrah!
Edit:A better batch file would make the new directories for you:
cd..
set debug=Output_Debug
set release=Output_Release
@if not exist %debug% md %debug%
@if not exist %release% md %release%
xcopy debug %debug% /Y
xcopy release %release% /Y
Andy Burns' Blog 
It was really helpful.
A very good solution
Another solution that worked for me (XP Pro 32bit) was to create a special ‘Deny’ permission for the Local Users (typically YOURCOMPUTERNAMEUsers in the list of users and groups). All you have to do is right click on the hidden .svn folder and choose properties from the context menu. Then click the security tab, choose the Users group and create an advanced permission by clicking the Advanced button. You will want to check the Deny checkbox for 1) “Delete” and 2) “Delete Subfolders and Files” permissions in the list box. Make sure you do this for the Users group.