C# Release Version Has Still .Pdb File

C# release version has still .pdb file

If you want to disable pdb file generation, you need to use the "Advanced build settings" dialog available in project properties after clicking the "Advanced..." button" located in the lower part of the Build tab.

Set Output - Debug info: to None for release build configuration and no pdb files will be generated.

Release generating .pdb files, why?

Because without the PDB files, it would be impossible to debug a "Release" build by anything other than address-level debugging. Optimizations really do a number on your code, making it very difficult to find the culprit if something goes wrong (say, an exception is thrown). Even setting breakpoints is extremely difficult, because lines of source code cannot be matched up one-to-one with (or even in the same order as) the generated assembly code. PDB files help you and the debugger out, making post-mortem debugging significantly easier.

You make the point that if your software is ready for release, you should have done all your debugging by then. While that's certainly true, there are a couple of important points to keep in mind:

1. You should also test and debug your application (before you release it) using the "Release" build. That's because turning optimizations on (they are disabled by default under the "Debug" configuration) can sometimes cause subtle bugs to appear that you wouldn't otherwise catch. When you're doing this debugging, you'll want the PDB symbols.

2. Customers frequently report edge cases and bugs that only crop up under "ideal" conditions. These are things that are almost impossible to reproduce in the lab because they rely on some whacky configuration of that user's machine. If they're particularly helpful customers, they'll report the exception that was thrown and provide you with a stack trace. Or they'll even let you borrow their machine to debug your software remotely. In either of those cases, you'll want the PDB files to assist you.

3. Profiling should always be done on "Release" builds with optimizations enabled. And once again, the PDB files come in handy, because they allow the assembly instructions being profiled to be mapped back to the source code that you actually wrote.

You can't go back and generate the PDB files after the compile.^* If you don't create them during the build, you've lost your opportunity. It doesn't hurt anything to create them. If you don't want to distribute them, you can simply omit them from your binaries. But if you later decide you want them, you're out of luck. Better to always generate them and archive a copy, just in case you ever need them.

If you really want to turn them off, that's always an option. In your project's Properties window, set the "Debug Info" option to "none" for any configuration you want to change.

Do note, however, that the "Debug" and "Release" configurations do by default use different settings for emitting debug information. You will want to keep this setting. The "Debug Info" option is set to "full" for a Debug build, which means that in addition to a PDB file, debugging symbol information is embedded into the assembly. You also get symbols that support cool features like edit-and-continue. In Release mode, the "pdb-only" option is selected, which, like it sounds, includes only the PDB file, without affecting the content of the assembly. So it's not quite as simple as the mere presence or absence of PDB files in your /bin directory. But assuming you use the "pdb-only" option, the PDB file's presence will in no way affect the run-time performance of your code.

_{^* As Marc Sherman points out in a comment, as long as your source code has not changed (or you can retrieve the original code from a version-control system), you can rebuild it and generate a matching PDB file. At least, usually. This works well most of the time, but the compiler is not guaranteed to generate identical binaries each time you compile the same code, so there may be subtle differences. Worse, if you have made any upgrades to your toolchain in the meantime (like applying a service pack for Visual Studio), the PDBs are even less likely to match. To guarantee the reliable generation of ex postfacto PDB files, you would need to archive not only the source code in your version-control system, but also the binaries for your entire build toolchain to ensure that you could precisely recreate the configuration of your build environment. It goes without saying that it is much easier to simply create and archive the PDB files.}

Debugging a release version of a DLL (with PDB file)

I finally found what cause the problems debugging a DLL that was built in release configuration:

First of all, it basically works as expected. Which means, if I have a DLL built in release-configuration plus the corresponding PDB file, then I can debug the classes/methods contained in that DLL.

When I first tried this, I unfortunately tried to step into methods of a class which has the DebuggerStepThroughAttribute, e.g:

[System.Diagnostics.DebuggerStepThrough]
public class MyClass {
    public void Test() { ... }
}

In that case, it is of course not possible to step into the method from the debugger (as expected/intended).

So everything works as intended. Thanks a lot for your answers.

Release Build contains extra files, do I need these?

You do (probably) need

• myApp.exe.config

That contains configuration settings for your executable.

You don't need the others.

• myApp.pdb

Contains debug symbols

• myApp.vshost.*

Used by Visual Studio when debugging (vshost means Visual Studio Host).

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

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.

Is there any setting in the code, config or visual studio to NOT generate .PDB file in published code?

If you right-click the project in the Solution Explorer and choose Properties, then go to the Build tab and click the Advanced button, you will see an option to control whether to generate debugging information. Set this to None in your release configuration and no PDB file will be generated.

What is a PDB file?

A PDB file contains information for the debugger to work with. There's less information in a Release build than in a Debug build anyway. But if you want it to not be generated at all, go to your project's Build properties, select the Release configuration, click on "Advanced..." and under "Debug Info" pick "None".

Release .dll and .pdb after loading .dll file dynamically

I found a solution to my problem. I tried a lot of solutions posted online, and they all had the same problem. Either the .dll file is being used by another process, or the .pdb file is being used by another process.

The code I have above, as I mentioned is working except for the .pdb file, which honestly I didn't find a solution to it. So, I worked around it. I have modified the build option so I don't produce the .pdb file at all.

In order to disable pdb file generation, you need to use the "Advanced build settings" dialog available in project properties after clicking the "Advanced..." button" located in the lower part of the Build tab.

Set Output - Debug info: to None for release build configuration and no pdb files will be generated.

This fixed my problem. Although it didn't really fix it, but I removed the file causing the problem. Hope this helps other

---

Related Topics