How to turn off pdb generation and vshost for all Release builds

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 specif开发者_开发问答ically) that I want to do that for all projects for the rest of time?

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.

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.

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.