I've an application built in VS2013
(written in C#
), how can I know if it was built in Debug or Release mode? Is it enough to check is files .pdb
are present?
It's not a duplicate of C# if/then directives for debug vs release .. suppose I don't have the source code, only compiled files, looking at them is it possible to determine the build mode? Can I just look for .pdb
files?
-
1PDB files can exist for release mode compiles as well. – Ron Beyer Nov 04 '15 at 15:24
-
@AntiHeadshot I would disagree, this isn't about defining directives, its asking how to determine if a compiled program was compiled in debug or release. – Ron Beyer Nov 04 '15 at 15:25
-
@RonBeyer yes and you get this by checking directives. The Question may not be the same but the answer is. – AntiHeadshot Nov 04 '15 at 15:26
-
@AntiHeadshot The directives do not exist anymore after you compile, they aren't placed in the compiled assembly anywhere, so you can't check for them *after* compilation. – Ron Beyer Nov 04 '15 at 15:26
-
1http://stackoverflow.com/questions/654450/programmatically-detecting-release-debug-mode-net – Rick S Nov 04 '15 at 15:28
-
Building in debug mode typically entails three things, first, turning off optimizations, and second, emitting debugging symbols, and third, defining DEBUG preprocessor symbol. Though these are usually done together, there is not a *requirement* that they be done together. Which, if any, do you actually care about? There *are* ways to detect each but they are different. – Eric Lippert Nov 04 '15 at 15:45
3 Answers
how can I know if it was built in Debug or Release mode? Is it enough to check is files .pdb are present?
Building in debug mode typically entails three things:
- Optimizations are disabled
- PDBs are emitted
- DEBUG preprocessor symbol is defined
I said "typically" because there is no requirement that any of these things happen consistently; it is possible to emit PDBs without optimizations, for example.
You do not say which of these three things you are interested in, or for that matter, why. I'll describe how to detect the first: was an assembly built with optimizations disabled?
The easiest way to do it is to simply run ILDASM on the assembly and examine the IL for any method. Methods built with optimization disabled will have nop
instructions throughout. These are "no operation" instructions which do nothing; they exist solely to make the code easier to debug by providing more locations upon which the developer can place breakpoints.
For example, the IL of a "hello world" method with optimizations disabled is:
nop
ldstr "Hello world"
call void [mscorlib]System.Console::WriteLine(string)
nop
ret
But with optimizations enabled, the nop
s go away.
If you are interested in other ways of detecting debug vs release mode, see the links in this duplicate question:

- 1
- 1

- 647,829
- 179
- 1,238
- 2,067
There are a couple of ways:
- File size is greater when built in debug vs release.
- If you follow a proper deploybuild then the release version should have updated assembly info.
- Use DebugView.exe, if the application shows debug output in DebugView then its built in Debug mode.

- 938
- 1
- 10
- 16
I used Dependency Walker on both a release and debug version of a test program.
In Dependency Walker, I did a save as type: Text with Import/Export Lists on both programs.
I then did a file compare of the outputs:
The only significant difference was that the Release version had a Page File Memory Used of Zero.

- 20,506
- 2
- 28
- 69