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?
相关问题
- Generic Generics in Managed C++
- How to know full paths to DLL's from .csproj f
- Importing NuGet references through a local project
- How to Debug/Register a Permanent WMI Event Which
- the application was unable to start correctly 0xc0
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:
I'm with Brian - you should keep these files. If you need to debug any bug or failure, you will need these files.
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.
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.