Since you can use reflector to reverse-engineer a .Net app, is there any reason to NOT ship the pdb files with the app? If you do ship them with it, then your stack trace will include the line number with the problem, which is useful if it crashes.
Please only enter 1 reason per comment for voting.
Shipping PDBs with your application allows easier reverse engineering as it contains local variable/object names, function prototypes, etc.
Apart from the fact that they are extremely heavy in any serious project? No, there´s no reason if you don't mind people reverse engineering your software.
Reflectors can get a high-level version of the MSIL code of your .NET application, but that doesn't mean it's necessarily usable/hackable... A lot of the code won't make sense to casual perusal without the names of private variables & functions along with other things that .NET Reflector cannot access without a PDB file.
Obviously if you're using any decent obfuscator (personally I like {smartassembly} but for its lack of cross-obfuscation), then you'll be losing out on all its protections just for the added value of line numbers, which isn't a really fair trade-off.
Anyway, line numbers are overrated!
Most people want to ship an optimised build. But if you ship a pdb with an optimised build, the source line numbers you get are likely to be off.
Shipping pdb does not give any additional convenience to user. So there are no reasons to ship pdb files with the app. Besides pdb file usually have large size.
Instead of shipping pdb files you should use local Microsoft Symbol Server for fast access to pdb files corresponding to error reports. Here you can find detailed explanation how to use Symbol Server.