C# dmp debug, can't load pdb file

1.  Project->Properties->Build->Advance,

Debug Info ： Full/pdb-only .

set to [none] will not generate pdb file.

2.when new version release , rebuild whole solution , copy all files to server.

 

what's the difference between C# compilation setting “/debug:pdbonly” and “/debug:full”?

The main difference is about performance.

Be aware that when you create a new project in Visual Studio, the Default configuration (/optimized- and /debug:full) ,produce unoptimized code. So the C # compiler will emit NOP (no-operation) instructions into the code. (The NOP instructions are emitted for example to enabled the “edit and continue” feature while debugging, or to allow breakpoints to be set on control flow instructions such as for, while, do, if , else, try, catch and finally ) impacting directly on the speed and size of the JIT optimized code.

On the other hand, In managed environment (.NET), compiling the code is accomplished in two phases. First, the compiler passes over the source code producing IL. Then, at run time the IL must be compiled into native CPU instructions requiring more memory to be allocated and requiring additional CPU time to do the work (JIT). So having an optimized IL code quality and an optimized JIT Native code quality by setting /optimized+ and /debug:pdbonly (default configuration for compilations if Release is chosen) could improve the performance of the application.

Moral of a fable, always compile in release mode when deliver your apps to the end users and you could gain a bit of performance.

 

 

Should I compile release builds with debug info as “full” or “pdb-only”?

I would build with pdb-only. You will not be able to attach a debugger to the released product, but if you get a crash dump, you can use Visual Studio or WinDBG to examine the stack traces and memory dumps at the time of the crash.

If you go with full rather than pdb-only, you'll get the same benefits, except that the executable can be attached directly to a debugger. You'll need to determine if this is reasonable given your product & customers.

Be sure to save the PDB files somewhere so that you can reference them when a crash report comes in. If you can set up a symbol server to store those debugging symbols, so much the better.

If you opt to build with none, you will have no recourse when there's a crash in the field. You won't be able to do any sort of after-the-fact examination of the crash, which could severely hamper your ability to track down the problem.

A note about performance:

Both John Robbins and Eric Lippert have written blog posts about the /debug flag, and they both indicate that this setting has zero performance impact. There is a separate /optimize flag which dictates whether the compiler should perform optimizations.

 

/debug (C# Compiler Options)

One difference between /debug:pdbonly and /debug:full is that with /debug:full the compiler emits a DebuggableAttribute, which is used to tell the JIT compiler that debug information is available. Therefore, you will get an error if your code contains the DebuggableAttribute set to false if you use /debug:full.