Visual Studio 2010 : Understanding Solutions and Projects (part 1)

Visual Studio uses logical containers — projects and solutions — for grouping all the code and resources associated with an application.

• Solutions contain all the projects necessary to build an application.

• Projects include all the source code and support files necessary to create the application.

For example, a solution may contain one project each for the following:

• Windows Forms

• Data-access code

• Database code

• Testing code

• The installer

The process of converting all the code found in a set of projects to an application is building or creating a build. Builds have settings that define where the output files are located and whether debug information is included. A group of settings is a build configuration. Visual Studio solutions and projects include two default build configurations:

• Debug: Code compiles with information for debugging and no optimization. The nature of the build is to enable you to test your code.

• Release: Code compiles with optimizations and no debugging information. The release configuration is intended for production deployment.

Builds can target a specific hardware platform, such as the 32-bit (x86) or 64-bit (x64) architectures. The Debug and Release build configurations provided by Visual Studio target the x86 architecture.

1. The anatomy of a build

Building software takes a set of inputs and creates a set of outputs. The inputs include the following:

• Source-code files

• Resource files

• Configuration files

• Local database files

The build process takes these files and converts them to a set of outputs that include

• Tokenized files, such as application executables and dynamic link libraries (DLLs). Binary files are assemblies.

• Debugging information, which is stored in a program database (PDB) file.

• Feedback messages, such as compiler warnings and errors.

The build process uses a compiler to convert your human-readable input files into machine-readable binary files. Each programming language uses its own compiler.

You use the outputs from a build to accomplish the following:

• Test an application you're developing.

• Deploy an application to a test or production environment.

• Determine whether you can check in your source code to form part of your source-code repository.

  Inputs to the build process — the source code — are checked in (established as source code) after you have a successful build.

Figure 1 shows the build process. Note that the outputs are deployed, but usually they're not checked into source code control.

Figure 1. The build process creates a set of deployable outputs.

2. Using the Build menu

Visual Studio provides a Build menu from which you can launch different build commands for your solution or project. The options on the Build menu are

• Build Solution: Compiles any source code that hasn't yet been compiled. The Build command doesn't delete any existing output files. Instead, the Build command performs an incremental build of any files not yet compiled.

• Rebuild Solution: Deletes, or cleans, any existing output files and compiles all source code into binary files.

• Clean Solution: Deletes all the output files generated by previous builds.

• Publish: Calls the Publishing Wizard to build and deploy the solution.

• Batch Build: Compiles multiple build configurations as a batch.

Deployable projects, such as SQL Server Reporting Projects, display the Deploy command on the Build menu. If you have the Web Deployment Project Add-In installed, you also have the option Add Web Deployment Project on the Build menu.

You execute build commands against solutions or individual projects. Here are some scenarios for how you can use the Build menu:

• Build projects individually when a solution has many projects. Compiling large solutions and projects is time consuming. For that reason, you may choose to build individual projects as you need them rather than building the entire solution. Using the Build command to incrementally compile source files can also save time.

• Build each project in a solution individually when a dependent project generates compile errors. When a solution has many projects that are dependent upon one another, an error in one project cascades to the dependent projects, which makes finding the original error difficult. Instead of plowing through a long list of errors and warnings, compile each project individually and deal with any errors you find.

• Build an entire solution. If your solution builds lightning-fast, you can use either the Build or the Rebuild Solution command.

  Use the Rebuild Solution option (rather than Build) if you're getting strange errors that you don't think you should be getting. Using Rebuild Solution wipes out all the previous build's outputs.

• Build individual projects as changes are made to them. When you have large projects and solutions, building is faster than rebuilding the entire solution.

Using the Start command from the Debug menu calls the Build command and executes your application. During development, many developers press the F5 key with the expectation that their code is going to build and execute.

Only after they see that long list of compiler errors do they start using the Build menu.

The commands on the Build menu correspond to targets files used by the Microsoft Build Engine (MSBuild).