We often come across .pdb files along with .dll files in the bin folder of any asp.net project. Now let’s understand it.
A program database (.pdb) file, also called a symbol file, maps the identifiers that you create in source files for classes, methods, and other code to the identifiers that are used in the compiled executables of your project. The .pdb file also maps the statements in the source code to the execution instructions in the executables. The debugger uses this information to determine two key pieces of information:
the source file and line number that are displayed in the Visual Studio IDE and the location in the executable to stop at when you set a breakpoint. A symbol file also contains the original location of the source files, and optionally, the location of a source server where the source files can be retrieved from.
When you debug a project in the Visual Studio IDE, the debugger knows exactly where to find the .pdb and source files for your code. If you want to debug code outside your project source code, such as the Windows or third-party code your project calls, you have to specify the location of the .pdb files (and optionally, the source files of the external code) and those files need to exactly match the build of the executables.
should I deploy .pdb files to production server or not
The PDB files allow Stack Traces of your code to be logged when your application throws an Unhandled Exception.
If your website has CustomErrors in the web.config set to OFF then your erroring code will be visible to everybody. This is not user friendly.
If your website has CustomErrors in the web.config set to ON or RemoteOnly then your erroring code will not be visible to the public, however you will be able to find the StackTrace in the server Event Log and this may help you to track down errors in your code. This is OK.
If you delete the PDBs (or stop then from publishing via your project build/publish configuration) then your site will not log your code in your Stack Trace, however it will log other stack information. In any case, always set CustomErrors in the web.config to ON or RemoteOnly. It completly depends upon your project requirement.