第 133 页

to achieve what you want. This chapter looks at the various build options available to you in

both Visual Basic and C#, outlining what the different settings do so you can customize them

to suit your own requirements.

In addition, you learn how Visual Studio 2010 uses the MSBuild engine to perform its

compilations and how you can get under the hood of the configuration files that control

the compilation of your projects.

General build oPtions

Before you even get started on a project, you can modify some settings in the Options pages

for Visual Studio 2010. These options apply to every project and solution that you open in

the IDE, and as such can be used to customize your general experience when it comes to

compiling your projects.

The first port of call for professional Visual Basic developers should be the General page of the

Projects and Solutions group. By default, the Visual Basic development settings of the IDE hide

some of the build options from view, so the only way to show them is to activate the Show

Advanced Build Configurations option.

912

.

chaPter 45 build cuSTomizATion

When this is active, the IDE displays the Build Configuration options in the My Project pages,

and the Build . Configuration Manager menu command also becomes accessible. Other language

environments don’t need to do this, because these options are activated on startup (although you

could certainly turn them off if you didn’t want them cluttering your menus and pages).

Two other options on this page relate to building your projects. One allows Visual Studio to

automatically show the Output window

when you start a build and the other allows

Visual Studio to automatically show the Error

window if compilation errors occur during

the build process. By default, all language

configurations have both of these options

turned on.

The Build and Run options page (shown

in Figure 45-1) in the Projects and Solutions

group has many more options available

to you to customize the way your builds

take place.

It’s unclear from this page, but some of these options affect only C11 projects, so it’s worth running

through each option, what it does, and what languages it affects:

.

Before Building: This tells Visual Studio how to handle changes that have been made to any

part of your project before the build process. You have four options:

.

Save All Changes automatically saves any changes without prompting you. This is

perhaps the best option, because you don’t have to remember to save your work.

This is the default setting.

.

Save Changes to Open Documents Only also automatically saves changes, but only

to open documents. This excludes some changes to solution and project files.

.

Prompt to Save All Changes gives you the chance to save any changes before the

build commences. When the build process is started, it displays a dialog prompting

you to save the changes or not. If you decline to save the changes, the build still

continues but uses the last saved version of the file. This option can be good to use

when you want to know when you’ve made changes (perhaps inadvertently) to the

source code.

.

Don’t Save Any Changes, as it suggests, doesn’t save changes to any files, open in

the editor or otherwise.

.

Maximum Number of Parallel Project Builds: This controls how many simultaneous build

processes can be active at any one time (assuming the solution being compiled has multiple

projects).

.

Only Build Startup Projects and Dependencies on Run: This option only builds the part of

the solution directly connected to the startup projects. This means that any projects that are

not dependencies for the startup projects are excluded from the default build process. This

option is active by default, so if you have a solution that has multiple projects called by the

fiGure 45-1

General Build options .

913

startup projects through late-bound calls or other similar means, they will not be built

automatically. You can either deactivate this option or manually build those projects

separately.

.

On Run, When Projects Are Out of Date: This option is used for C++ projects only and

gives you three options for out-of-date projects (projects that have changed since the last

build). The default is Prompt to Build, which forces the build process to occur whenever you

run the application. The Never Build option always uses the previous build of out-of-date

projects, and the Prompt to Build gives you an option to build for each out-of-date project.

Note that this only applies to the Run command, and if you force a build through the Build

menu, projects are rebuilt according to the other settings in the build configuration and on

this Options page.

.

On Run, When Build or Deployment Errors Occur: This controls the action to take when

errors occur during the build process. Despite official documentation to the contrary, this

option does indeed affect the behavior of builds in Visual Basic and C#. Your options here

are the default Prompt to Launch, which displays a dialog prompting you for which action

to take; Do Not Launch, which does not start the solution and returns to design time; and

Launch Old Version, which ignores compilation errors and runs the last successful build of

the project.

The option to launch an old version enables you to ignore errors in subordinate projects and

still run your application; but because it doesn’t warn you that errors occurred, you run the

risk of getting confused about what version of the project is active.

Note that when you use the Prompt to Launch option, if you subsequently check the Do

Not Show This Dialog Again option in the prompt dialog, this setting is updated to either

Do Not Launch or Launch Old Version, depending on whether or not you to choose to

continue.

It is recommended that you set this property to Do Not Launch because this can

improve the efficiency with which you write and debug code — one fewer

window to dismiss!

.

For New Solutions Use the Currently Selected Project as the Startup Project: This option

is useful when you’re building a solution with multiple projects. When the solution is being

built, the Visual Studio build process assumes that the currently selected project is the startup

project and determines all dependencies and the starting point for execution from there.

.

MSBuild Project Build Output Verbosity: Visual Studio 2010 uses the MSBuild engine for

its compilation. MSBuild produces its own set of compilation outputs, reporting on the

state of each project as it’s built. You have the option to control how much of this output

is reported to you:

.

By default, the MSBuild verbosity is set to Minimal, which produces only a very

small amount of information about each project, but you can turn it off completely

by setting this option to Quiet, or expand on the information you get by choosing

one of the more detailed verbosity settings.

914

.

chaPter 45 build cuSTomizATion

.

MSBuild output is sent to the Output window, which is accessible via View . Other

Windows . Output (under some environmental setups this will be View .

Output).

If you can’t see your build output, make sure you have set the Show Output From

option to Build (see Figure 45-2).

fiGure 45-2

.

MSBuild Project Log File Verbosity: When Visual Studio builds a C++ project, it generates a

text-based log file of MSBuild activities as well as the normal information that goes to the

Output window. The amount of information that goes into this text file can be controlled

independently using this option. One way to take advantage of this is to have more detailed

information go into the log file and leave the Output window set to Minimal, which

streamlines the normal development experience but gives you access to more detailed

information when things go wrong. If you do not want Visual Studio to produce this

separate log file, you can turn it off using the Projects and Solutions .

VC + + Project

Settings . Build Logging setting.

It’s also worth taking a look at the other Options pages in the Projects and Solutions category,

because they control the default Visual Basic compilation options (Option Explicit, Option Strict,

Option Compare, and Option Infer), and other C++-specific options relating to build. Of note for

C++ developers is the capability to specify PATH variables for the different component types of

their projects, such as executables and include files, for different platform builds; and whether to

log the build output (see the preceding list).

Manual dePendencies

Visual Studio 2010 is able to detect inter-project dependencies between projects that reference each

other. This is then used to determine the order in which projects are built. Unfortunately, in some

circumstances Visual Studio can’t determine these dependencies, such as when you have custom

steps in the build process. Luckily, you can manually define project dependencies to indicate how

projects are related to each other. You can access the dialog shown in Figure 45-3 by selecting either

the Project . Project Dependencies or Project . Build Order menu commands.

Note that these menu commands are available only when you have a solution

with multiple projects in the IDE.

The Visual Basic Compile Page .

915

You first select the project that is dependent on others

from the drop-down, and then check the projects it

depends on in the bottom list. Any dependencies that are

automatically detected by Visual Studio 2010 will already

be marked in this list. The Build Order tab can be used to

confirm the order in which the projects will be built.

the Visual basic coMPile PaGe

Visual Basic projects have an additional set of options that

control how the build process will occur. To access the

compile options for a specific project, open My Project

by double-clicking its entry in the Solution Explorer.

When the project Options page is shown, navigate to the

Compile page from the list on the left side (see Figure 45-4).

fiGure 45-3

fiGure 45-4

The Build Output Path option controls where the executable version (application or DLL) of your

project is stored. For Visual Basic, the default setting is the bin\Debug\ or bin\Release\

directory

(depending on the current configuration), but you can change this by browsing to the desired location.

It is recommended that you enable the Treat All Warnings as Errors option

because this will, in most cases, encourage you to write better, less error-prone

code.

916

.

chaPter 45 build cuSTomizATion

You should be aware of two additional sets of hidden options. The Build Events button in the lower-

right corner is available to Visual Basic developers who want to run actions or scripts before or

after the build has been performed. They are discussed in a moment. The other button is labeled

Advanced Compile Options.

advanced compiler settings

Clicking the Advanced Compile Options

button displays the Advanced Compiler

Settings dialog (see Figure 45-5) in which

you can fine-tune the build process for

the selected project, with settings divided

into two broad groups: Optimizations and

Compilation Constants.

optimizations

The settings in the Optimizations group

control how the compilation is performed to

make the build output or the build process

itself faster or to minimize the output size.

Normally, you can leave these options alone,

but if you do require tweaks to your compilation, here’s a summary of what each option does:

.

Remove Integer Overflow Checks: By default, your code is checked for any instance of a

possible integer overflow, which can be a potential cause for memory leaks. Deactivating

this option removes those checks, resulting in a faster-running executable at the expense

of safety.

.

Enable Optimizations: Optimizing the build may result in faster execution with the penalty

being that it takes marginally longer to build.

.

DLL Base Address: This option enables you to specify the base address of the DLL in

hexadecimal format. This option is disabled when the project type will not produce a DLL.

.

Generate Debug Info: This controls when debug information will be generated into your

application output. By default, this option is set to full (for Debug configurations), which

enables you to attach the debugger to a running application. You can also turn debugging

information off completely or set the option to pdb-only (the default for Release

configurations) to only generate the PDB debugging information. The latter means that

you can still debug the application when it is started from within Visual Studio 2010

but you will only be able to see the disassembler if you try to attach to a running

application.

Compilation Constants

Compilation constants can be used to control what information is included in the build output and

even what code is compiled. The Compilation Constants options control the following:

fiGure 45-5

The Visual Basic Compile Page .

917

.

Define DEBUG Constant and Define TRACE Constant: Enable debug and trace

information to be included in the compiled application based on the DEBUG and TRACE flags,

respectively.

.

Custom Constants: If your application build process requires custom constants, you can

specify them here in the form ConstantName=“ Value ” . If you have multiple constants, they

should be delimited by commas.

The last three options don’t really fall under compilation constants, but they do allow you to further

customize the way the project builds.

.

Generate Serialization Assemblies: By default this option is set to Auto, which enables the

build process to determine whether serialization assemblies are needed, but you can change

it to On or Off if you want to hard-code the behavior.

Serialization assemblies are created using the Sgen.exe command-line tool. This