It’s a fair question. There are lots of folks who will say “deploying with .pdb’s kill performance”…to some extent this is true, but not as true as some folks would like to think, especially with machines running as fast as they do lately. That being said, there are really 2 different development scenarios that deploying with .pdb’s applies to:
- A corporate IT setting.
- An independent software vendor (ISV) setting.
In an IT setting, the environment is usually (hopefully) much more controlled than in a scenario where an ISV develops a product and ships it to a remote location that they have no control over. I come from more of the IT realm, but I’ll attempt to cover both camps.
As it relates to corporate IT, deploying .pdb’s with your project actually isn’t as bad as it appears at first glance. From my experience, it actually makes a lot of sense…when stuff comes crashing down it’s just that much easier/quicker to fire up a debugger, attach to the remote machine, and get stuff working again. Something else I’ve come across (in what I thought was a well known secret, but apparently still is not) is that a lot of folks don’t realize that an application doesn’t have to be deployed in a debug build to be debugged. You can instruct the compiler to generate .pdb’s for any type of build (debug/release/etc); so long as the .pdb files are present, a debugger can be attached (so long as debugging is enabled in the application). The flip side to that is applications deployed as a debug build don’t need the .pdb’s to run (though that’s an unlikely scenario) so long as debugging is turned off. And that’s the key…it boils down to whether the application is set up to be debugged. If it’s not, the .pdb’s won’t be loaded and will sit there harmlessly. Of course enabling debugging in an application means an application restart which is generally unacceptable in a corporate setting so it may be a good idea to leave debugging enabled depending on your situation, and of course if debugging is enabled the .pdb’s are expected to be there. That all being said, you should always deploy an application with optimizations turned on as they will almost always run faster than sans ops.
A good rule of thumb is to generate .pdb files for all of your builds, regardless of if you are actually going to deploy said .pdb’s with the application; one reason being that the .pdb’s generated during the default debug build process in Visual Studio more than likely won’t be compatible with with a default release build…the reason is simple enough, default debug builds have optimizations off, while the default release configuration has optimizations turned on. I’ve come across some strangeness in the past attempting to use .pdb’s generated for debug in a release build. They might work, they might not…eventually they’ll hit some code that wasn’t optimized in the debug build that is optimized in the release build…it’s an interesting sight to say the least and has left me scratching my head on more than one occasion in the past, only to realize the .pdb’s didn’t match the build configuration they were expecting. The main point is that since IT is in a controlled setting, deploying .pdb’s doesn’t have the potential ramifications as it would for ISV’s as the development environment is only accessible by the developers themselves.
As it relates to ISV’s, it is most certainly not a good idea to ship your .pdb’s with your application; mainly because you don’t want your customers making their own fixes (if they’re technically savvy enough) as that would fragment the application…bug fixes need to remain centralized for quality control, and you don’t want them to even have the option to fix bugs. More importantly however…once you have the .pdb’s to an application, you basically have the secret sauce as your entire application can be stepped through and completely reverse engineered if someone chose to do so (perhaps one of your competitors). Of course I realize that anyone can fire up reflector (or ILDASM) and decompile an assembly, but .pdb’s make this much easier to do as everything is pretty much out in the open.
Regardless of what setting you find yourself in, .pdb’s need to be treated as first class citizens just like there assembly brethren. They should be versioned and stored in a source repository in a subdirectory in the application tree, and stored securely somewhere else as well. When it comes time to head off to a client site to fix some strangeness that only they are seeing (which happens more often than not), simply grab the .pdb’s from source control that match the version of their application, put ‘em on a disc, drop ‘em in the application, and debug away.
So, to summarize:
- Generate .pdb’s for all build configurations, regardless of if you’re going to deploy them or not.
- Version them, and give them their own subdirectory (or even their own project depending on the size of the application) in source control, and make sure to use the same versioning scheme as your assemblies to make sure they match should a problem crop up down the line.
- Deploying .pdb’s in a controlled IT setting isn’t necessarily a bad thing, especially if it’s a new project/major release. The ease of being able to fix issues on the fly (production debugging) will more than likely offset any perceived performance issues of having the .pdb’s loaded into memory. The trick is knowing when to have debugging enabled in the application so as to negate an application restart to load the .pdb’s, again hardware is fast enough these days that leaving it on (after initial deployment) won’t bring an application to it’s knees as many think. Once you’re sure it’s stable you can always switch it off.
- Deploying .pdb’s if you’re an ISV is generally not a good idea, unless your customer has a dedicated IT department who will be maintaining the application after you ship it…if that’s the case there needs to be a centralized repository that both you and the customer have access to so as to avoid fragmentation of your product. If not, keep the .pdb’s separate (and secure).
Sorry for the long winded post, but I’ve seen .pdb abuse more often than not, and it’s one of those things that you don’t really see mentioned all that often. So I thought I would mention it.