Every time I start a new piece of software I have to go into the configuration and turn off pdb file generation and the Visual Studio hosting process for Release builds. Is there any way to tell Visual Studio (2008 specifically) that I want to do that for all projects for the rest of time?
-
Why would you want to turn off PDBs for release builds? See http://stackoverflow.com/questions/2371032 – Brian Rasmussen Mar 16 '10 at 11:27
-
1I work on mostly internal software and we don't have automated builds (yet) so it's just another file to ship/deselect prior to passing the build to the guys who roll out the software. I'm just trying to make things as clean & easy as possible for them and me. – Dave D Mar 16 '10 at 11:31
-
But not providing PDBs will make it harder to debug. – Brian Rasmussen Mar 16 '10 at 11:37
-
6I would like to turn off the darn hosting process once and for all though so +1 from me. – Brian Rasmussen Mar 16 '10 at 11:58
-
Good question. I hate that the vshost.exe always shows up in my release builds. – Scott Marlowe Apr 22 '10 at 14:47
3 Answers
In VS 2010 you will find a project property to control .pdb generation under Project Properties -> Build -> Advanced... -> Debug Info
Set this to "none" to suppress .pdb generation.

- 13,011
- 11
- 78
- 98
-
1That's on a per project basis though. At the time I wanted to do this once for all projects forever, rather than having to go into each project as it was set up and change it. – Dave D Apr 10 '13 at 11:52
After some digging around, it appears that project files for C# are stored in \program files\microsoft visual studio 9.0\common7\ide\projecttemplatescache\csharp\windows\1033
. By adding <UseVSHostingProcess>false</UseVSHostingProcess>
to the correct sections (there are separate sections for Debug and Release configurations) of the relevant templates, you can turn off the hosting process for all future projects of the selected types.
You should be able to handle the PDB issue in a similar way, but as I said I don't recommend turning those off, so I'll leave it as an exercise :)
This applies to VS2008, but my guess is that other editions have a similar scheme. In fact, VS2010 uses the same approach, but obviously the version number in the directory is 10.0 instead of 9.0.

- 114,645
- 34
- 221
- 317
-
For the record, and since Google led me to that thread, this trick applies to VS2012 too (at least for hosting process, I don't want to disable PDB files so didn't try). Thanks again, you made my day! – psycho Jun 19 '13 at 09:43
-
Turning this off in my `.csproj` file caused `MSB3027` when compiling. That is, the output file cannot be written since it is locked. – l33t Oct 07 '13 at 10:33
-
@l33t Did you remember to close the file? If it is still open it will be locked. I just verified this on VS2012. – Brian Rasmussen Oct 07 '13 at 15:53
-
I made the change directly in my own `.csproj` so I believe the file was opened by Visual Studio. – l33t Oct 14 '13 at 13:30
-
@l33t if you just want to change this for the current project, you can just go to the debug setting for the project. No need to edit the `.csproj` file for that. – Brian Rasmussen Oct 16 '13 at 01:01
Why not add a post build step that deletes these files you don't want. Hmm, that still another step, not what you wanted :-(
What about writing a little helper app that does a FindFirstFile and FindNextFile loop looking for PDB and shost files in your release directories. When it finds them, it deletes them. Or better still moves them to an archive location - this allows to remove them from the release packaging issues but still keep the files in case you need them for bug analysis.
Plus because its a helper app you can just run it once as part of your pre-handoff to release staff.
We use this technique for lots of things:
- Ensuring DLLs are up to date (basically an intelligent update for the whole build tree)
- Cleaning VC builds better than "batch build" can (removing some of those files that can crash Visual Studio)
- Archiving certain in a particular fashion (similar to what I've suggested for you)
- etc
I'm with Brian - you should keep these files. If you need to debug any bug or failure, you will need these files.

- 3,078
- 1
- 22
- 25
-
I agree -- don't suppress them or delete the PDBs -- just remove them from the deployment package and archive them along with your build: http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx – Randy Levy Mar 16 '10 at 13:04