Understanding Application Builds

Applications go through a cycle of iterative builds throughout the development process. This cycle continues even after the application has been deployed to production as a release build. The term build configuration refers to the settings and configurations incorporated into a specific build. A build configuration controls the application build settings, including the files and components to be built. You can tailor a build configuration to a target platform. In addition, it contains settings that define the level of support for debugging and tracing in the compiled build. You can define two levels of build configuration in VS .NET:

• Solution build configurations: These are composed of a set of project configurations where each project entry in the solution build configuration includes the name of the project, the type of build, and the platform supported. The set of entries together specifies how the projects in the solution are to be built and deployed.

• Project configurations: These are a set of defined project properties that control how a project is to be built and deployed.

The build configuration is a useful tool during the development process because it helps developers manage the configuration of builds for different targeted platforms, including development, quality assurance, staging, and production. Builds for the development environment do not have the same configuration as builds for the Quality Assurance (QA) environment, and both are in turn different from production environment builds. Development builds, for example, can support debugging symbols, whereas production builds will not. The build created by each associated build configuration is called a build type . VS .NET has two default build types: a debug build and a release build.

Debug Builds vs. Release Builds

There are distinct differences between a debug build and a release build. As the names imply, the debug build is for debugging purposes, and the release build is for deployment to a production environment. VS .NET automatically creates the configurations for the debug and release build types and sets the appropriate default options and settings. The default settings for each build type are as follows :

• The debug configuration of the project or solution is compiled with full symbolic debug information.

• The release configuration of the project or solution is fully optimized and contains no symbolic debug information. Debug information is still generated in separate Programmer Database ( *.pdb ) files, although they are not linked to the project.

Build configurations change throughout the development lifecycle as the application moves between different environments, including the development, test, and production environments. Each build environment has its own purpose and requires differences in the way that you compile the build. The build configuration for each environment addresses these variations. Figure 8-1 shows the typical environments and build characteristics for each build configuration.

Figure 8-1: Build configurations for application environments

While the project or solution is in development, the debug build is often used to compile and test the project or solution. Debug builds are compiled repeatedly throughout the development lifecycle as new functionality is added and as bugs and exceptions are fixed. The build configuration at this stage is constantly changing to incorporate new components and to troubleshoot and finalize the build configuration. Exception resolution in the application at this stage usually involves two steps. First, compilation exceptions such as incorrect syntax, misspelled keywords, and type mismatches are corrected as they are encountered during the build process. Modern compilers and IDEs catch most of these exceptions up front and prevent the build from completing successfully until they are resolved. Second, debugging tools find and correct exceptions caused by logical and semantic issues in the code. These exceptions may make it into the build and then turn up at runtime during unit testing (or worse , in production, if the exception is not caught).

In the development environment, the build type is called the debug build . This build type is compiled with debug symbols and typically includes strategically located tracing information. The debug build usually has the following characteristics:

• Debug mode is enabled.

• Trace mode is enabled.

• Some components are excluded from the build so that the developer can focus on testing a more limited section of the application.

Debug builds are often not used when the project or solution is ready for formal QA testing. In this environment, the compilations errors have already been resolved and developers have tested the components within the project or application. The exceptions encountered in this environment are usually integration errors and logical program flow exceptions unforeseen by the developer. To troubleshoot and resolve these exceptions, it is common to have trace mode enabled, and optionally have debug mode enabled also. Whether you enable debug mode depends on what the goals are for the formal testing. Typically, unit testing is focused on identifying exceptions, and on gathering as much information as possible when exceptions do occur. The goal of unit testing is to communicate back to the developer what the exceptions are, and what is known about them, so that the developer can resolve the problems. Debug information has an important role to play in this effort.

If performance measurement is one of the testing goals, then you will not compile the project in debug mode, since this mode creates bigger, slower builds that have an adverse effect on performance. In this case, you will want to mirror the build that will go into production, so you would want to compile the project in Release mode. The release build type uses the same build configuration as will be used for the production-ready release build.

The custom build type is a compromise between the standard debug and release build types. A custom build configuration can be based off either the default debug build or release build configuration. It is useful for creating a test build in development for testing a variety of issues and features. The custom build type selectively excludes components and files that are not ready-for the build. The custom build type usually has the following characteristics:

• Debug mode is either enabled or disabled

• Trace mode is enabled

• Some components and files are excluded from the build

An important factor in configuring a custom build is to identify the interactions between components within the project or application. Care must be used to make sure the exclusion of components does not adversely affect or negate the testing performed on the components included in the build.

Once the project or solution is fully developed and sufficiently debugged to pass unit testing, you are ready to compile the application into a release build. The release build is characterized by the following:

• Debug mode is disabled

• Trace mode is enabled

• All application components and files are included in the build

Release builds are smaller and faster than debug builds, because they are compiled with optimizations and without debugging symbols. Optimizations are typically excluded from debug builds, because they complicate the relationship between source code and generated instructions. Debug builds, on the other hand, use a simpler compilation algorithm. Release builds may contain tracing information that can be conditionally activated to diagnose issues in the production environment that are not readily observed in the development and test environments.

Setting the Build Configuration

The settings for each build type reside in the project and solution configurations. Because there can be multiple projects in a solution, there can be multiple project configurations associated with a solution configuration.

You manage the relationships between solution and project configurations through the Configuration Manager in VS .NET. You access the Configuration Manager from three locations within VS .NET: the Build menu; the Solution Configurations drop-down list in the main toolbar; or the solution's property pages (discussed in the "Managing Solution Configurations" section). Figure 8-2 shows the Configuration Manager dialog box for the AspNetChap8 and AspNetChap8A sample projects that accompany this chapter.

Figure 8-2: The Configuration Manager dialog box

Table 8-1 describes each element in the dialog box.

Table 8-1: Configuration Manager Elements

ELEMENT NAME	DESCRIPTION
Active Solution Configuration	Displays the solution build configurations defined in VS .NET. You can change the solution build configuration here or in the Solution Configurations drop-down list on the main toolbar. The drop-down list gives the option to create a new solution configuration with the New menu item or edit an existing configuration with the Edit menu item.
Project Contexts	Project Contexts displays the project name, a drop-down list of project configurations and platforms, and check boxes for selecting the projects to be built and (if enabled) deployed. Each combination of project configuration and platform chosen determines the project configuration that will be used. You can sort the columns by clicking the column names.
Project	Displays the project names found in the current solution.
Configuration	Displays the project build configurations available. The dropdown list gives the option to create a new project build configuration or rename an existing build configuration using New or Edit.
Platform	Displays the platforms available for the project. The dropdown list gives the option to add a new platform or edit an existing one using New or Edit. The type of project determines what platforms are available. There is a one-to-one correspondence between project configurations and platforms. When you add a new platform to the project, it creates a new project configuration.
Build	Specifies whether to build this project. An unchecked project will not be built, even if there are project dependencies on the project.

The Configuration Manager allows you to manage the specific solution build configurations and project configurations you want set up at any specific time. For solutions with multiple projects, this is a useful tool to manage the project configurations as it relates to the solution configuration. As Figure 8-2 shows, you can assign different project configurations to a solution configuration. In the sample, the scenario could be that AspNetChap8 is ready for testing, but AspNetChap8A is still in development. In this case, you can assign a solution configuration called "Test," which consists of a release build of AspNetChap8 project and a debug build of AspNetChap8A.

Managing Solution Configurations

You manage the solution configuration using the solution's property pages. You can open these property pages in two ways:

• Right-click the VS .NET solution file in the Solution Explorer window. Select Properties from the pop-up menu.

• Highlight the solution file in the Solutions Explorer window, and then select Properties from the Project menu.

The solution's property pages, which has different properties from the project's property pages, offer the ability to do the following tasks :

• Determine in what order projects run in the debugger

• Determine in what order projects build using dependencies

• Define and edit solution and project build configurations

Figure 8-3 shows the sample property pages for the AspNetChap8 solution. The solution contains two projects, AspNetChap8 and AspNetChap8A. Table 8-2 describes each tag.

Table 8-2: Elements of the Solution Property Pages

OPTION NAME	DESCRIPTION
Startup Project	Assigns the startup project to run when the debugger is started. It can be specified as a Single Startup Project, where only one project is started, or as Multiple Startup Projects, where more than one project is run when you start the debugger. If you select Multiple Startup Projects, then each project can be assigned one of the following actions from the pull-down list: Start : Run the project when the debugger is started. Start without Debugging : Run the project when the debugger is started, but do not debug this project. None: Do not run this project when you start the debugger.
Project Dependencies	Sets the project dependencies, if any, for the projects in the solution. The dependency is defined as "Project AspNetChap8A depends on Project AspNetChap8." Setting project dependencies determines the build order for the projects; in this case, AspNetChap8 would be built before AspNetChap8A.
Configuration Properties Configuration	Function and layout are similar to the Configuration Manager. Here you can set how different versions of solutions and their projects will be built.

Figure 8-3: Sample solution property pages

Managing Project Configurations

You define the project configurations using the property pages. The project configurations are sets of properties for each supported combination of build and platform (for example, Debug .NET or Release Win32). For ASP.NET applications, the only supported platform option is .NET. In this dialog box, you can manage the project's Common Properties and Configuration Properties. The properties are saved in the project's .vbproj file.

The Common Properties contain the following groups of parameters:

• General: Sets the relevant information about the current project including the assembly name, output type, startup object, and root namespace.

• Build (Common Properties): Sets the compilation defaults including the compiler options and the application icon

• Designer Defaults: Sets the page layout, the target schema, and the clientside script language

• Imports: Sets the namespaces for this application

• Reference Path : Sets where the reference files are to be stored

• Web Settings: Sets the defaults for Web projects, including offline behavior and Web access method

The Configuration properties contain the following groups of parameters:

• Debugging: Sets the start project, sets the start options including command-line arguments, and sets the debugger to enable for this build

• Optimization: Sets the types of optimization including removing integer overflow checks, enabling optimizations, and enabling incremental builds

• Build (Configuration Properties): Sets the output path, specifies whether to emit debugging information, and controls whether warnings will be raised

• Deployment: Specifies the configuration override file (if any) to use during compilation

To open the project's property pages, select the desired project or projects in Solution Explorer. On the Project menu, select Properties. Figure 8-4 shows the sample project's property pages for the AspNetChap8 project.

Figure 8-4: Sample project's property pages

To create a new project configuration, click the Configuration Manager button on the upper-right corner of the dialog box. Within the Configuration Manager, select New from the Configuration pull-down list, enter a configuration name, select whether you want to create a separate solution for the new configuration, and click OK. The new configuration will then be available from the pull-down list in the property pages.

The Debugging Tab

The Debugging tab allows you to specify additional actions when the project goes into run mode. You can take these two actions:

• Start Action: Indicates the item to start when the application is debugged: the project, a custom program, a Uniform Resource Locator (URL), or nothing. By default, the Start Project option is enabled.

• ASP.NET Debugging: Determines if the debugger should attach to the server to enable debugging of ASP.NET pages.

The Build Tab

The Build tab allows you to set the attributes for the project's executable or build output. You can set these properties:

• Generate Debugging Information: Specifies whether the application should enable debugging information. By default, debug information is enabled for the Debug configuration and disabled for the Release configuration.

• Register for COM Interop: Specifies the compilation output to be a COM Callable wrapper for your class library and registers it with the operating system similar to RegSvr32.exe . The option is only available if the Output Type property of this application is a class library and if the class library assembly is strongly named.

• Warnings: Specifies whether warnings are enabled during compilation and how they will be handled.

• Enable build warnings: Directs the build warnings to the Task List. The developer can utilize the Task List to track the warnings.

• Treat warnings as errors: Directs the compiler to treat build warnings as errors. If a warning occurs, the compiler will not produce an application output file.

• Define DEBUG constant: Defines and passes the DEBUG=1 constant to the compiler. Debug class statements are compiled in the output.

• Define TRACE constant: Defines and passes the TRACE=1 constant to the compiler. Trace class statements are compiled in the output.

The Deployment Tab

The Deployment tab contains one property, Configuration Override File. It specifies a Web configuration file with which to build and deploy the project. The selected *.config file will be renamed to Web.config when the project is deployed. You should maintain separate Web.config files for each environment you will be building for, such as the development server or the production server. This property applies only to ASP.NET applications.

Executing Compilation and Conditional Compilation

Both the trace and debug modes have associated conditional attributes. You can enable or disable the trace and debug modes independently. Thus, there are four possible cases: debug, trace, both, or neither . The release build in production does not have to enable tracing, but it is often useful to do so. Debug builds typically enables both debugging and tracing.

You can set the conditional attributes in the compiler settings in several ways:

• The project's property pages

• The command line

• #CONST (for Visual Basic) and #define (for C#)

The conditional attributes for debugging and tracing are in the Build (Configuration Properties) tag in the project's property pages.

• In VB .NET, select the check boxes to enable the two properties: Define TRACE constant and Define DEBUG constant.

• In C#, type the name of the setting you want to enable into the Conditional Compilation Constants field. Because C# is case sensitive, the names must be uppercase. For example, to define both debugging and tracing, you must enter the following text into the field: DEBUG;TRACE (note the use of a semicolon as the delimiter between the constants).

To set the debugging and tracing attributes from the command-line compiler, use the conditional compiler constants specific to the language ”in this case, /d or /define . Enter the following switches in the command line:

• VB .NET: /d:TRACE=TRUE /d:DEBUG=FALSE

• C#: /d:TRACE /d:DEBUG=FALSE

Likewise, you can execute conditional compilation within the code using the specific language directive, #CONST or #define . Type the suitable statement at the top of the source code file before any class or function code blocks.

In VB .NET, enter the following:

 #CONST <ATTRIBUTE> = <true.false> where ATTRIBUTE = TRACE or DEBUG and true = enable 

In C#, enter the following:

 #<define/undefine> <ATTRIBUTE> where ATTRIBUTE = TRACE or DEBUG and define = true