C# 4 and .NET 4

396 ❘ ChaPTer 16 visuAl studiO 2010
Debugger Symbols
When you are debugging, you often have to look at values of variables, and you will specify them by their
source code names. The trouble is that executable code generally does not contain those names — the
compiler replaces the names with memory addresses. .NET has modified this situation somewhat to
the extent that certain items in assemblies are stored with their names, but this is only true of a small
minority of items — such as public classes and methods — and those names will still be removed when
the assembly is JIT-compiled. Asking the debugger to tell you what the value is in the variable called
HeightInInches is not going to get you very far if, when the debugger examines the executable code, it
sees only addresses and no reference to the name HeightInInches anywhere. Therefore, to debug properly,
you need to have extra debugging information made available in the executable. This information includes,
among other things, names of variables and line information that allows the debugger to match up which
executable machine assembly language instructions correspond to your original source code instructions.
You will not, however, want that information in a release build, both for commercial reasons (debugging
information makes it a lot easier for other people to disassemble your code) and because it increases the size
of the executable.
Extra Source Code Debugging Commands
A related issue is that quite often while you are debugging there will be extra lines in your code to display
crucial debugging-related information. Obviously, you want the relevant commands removed entirely
from the executable before you ship the software. You could do this manually, but wouldn’t it be so much
easier if you could simply mark those statements in some way so that the compiler ignores them when it is
compiling your code to be shipped You’ve already seen in the first part of the book how this can be done
in C# by defining a suitable processor symbol, and possibly using this in conjunction with the Conditional
attribute, giving you what is known as conditional compilation.
What all these factors add up to is that you need to compile almost all commercial software in a slightly
different way when debugging than in the final product that is shipped. Visual Studio is able to consider
this because, as you have already seen, it stores details of all the options that it is supposed to pass to the
compiler when it has your code compiled. All that Visual Studio has to do to support different types of
builds is to store more than one set of such details. The different sets of build information are referred to as
configurations. When you create a project, Visual Studio automatically gives you two configurations, called
Debug and Release:
➤
➤
The Debug configuration commonly specifies that no optimizations are to take place, extra debugging
information is to be present in the executable, and the compiler is to assume that the debug preprocessor
symbol Debug is present unless it is explicitly #undefined in the source code.
The Release configuration specifies that the compiler should optimize the compilation, that there
should be no extra debugging information in the executable, and that the compiler should not assume
that any particular preprocessor symbol is present.
You can define your own configurations as well. You might want to do this, for example, if you want to set
up professional-level builds and enterprise-level builds so that you can ship two versions of the software. In
the past, because of issues concerning the Unicode character encodings being supported on Windows NT
but not on Windows 95, it was common for C++ projects to feature a Unicode configuration and an MBCS
(multi-byte character set) configuration.
selecting a Configuration
One obvious question is that, because Visual Studio stores details of more than one configuration, how does
it determine which one to use when arranging for a project to be built The answer is that there is always
an active configuration, which is the configuration that will be used when you ask Visual Studio to build a
project. (Note that configurations are set for each project rather than for each solution.)
www.it-ebooks.info