Nearly everything you do in Microsoft® Visual Studio® 2005 revolves around solutions and projects. In this chapter, we'll talk about solutions and projects in detail and give you a good understanding of what those terms really mean. We'll also describe project management in Visual Studio 2005 and explain how you can organize your software projects to maximize the features of the integrated development environment (IDE).
Managing complex software projects can be a difficult and messy affair. Visual Studio 2005 helps by organizing programming projects as solutions (groups of projects) and projects and by handling references to assemblies and to components outside this structure. This organization and reference feature helps promote code reuse by allowing you to take advantage of related projects, existing assemblies, COM components, and source code. The easiest way to reuse Microsoft .NET code is through references to assemblies in your projects and solutions.
Important
Visual Studio 2005 organizes software projects on two conceptual levels. Solutions contain projects and solution items. Projects contain the source files that are compiled into executables and assemblies.
The most important tool for project management in Visual Studio 2005 is Solution Explorer (Ctrl+Alt+L), shown in Figure 2-1. Solution Explorer uses a tree-view window to provide access to all the projects and files that are part of the currently open solution. Visual Studio 2005 can host one solution at a time, but you can run multiple instances of Visual Studio if you want to work with multiple solutions concurrently.
Most new projects in Visual Studio 2005 are created using a template developed by a language integrator. For example, Visual Studio 2005 ships with support for Microsoft Visual Basic®, Visual C#®, Visual J#®, and Visual C++®. Each of these languages features a number of project types that programmers can choose from when creating a new project. A new project is created as part of a new solution by default. You can also add projects to existing solutions.
For Windows Forms applications and unmanaged Microsoft Windows®–based applications, the solution file for a project is by default stored in the same folder as the project. For Web applications, solution files are typically stored in a folder in the Visual Studio Projects folder in your My Documents folder and point to the Web server that's hosting the application.
A single project can be a member of many different solutions. Because it's so easy to reorganize your projects in Visual Studio 2005, you should feel free to create your initial projects with default solutions. Later on, you can move your projects around and add them to new solutions if you want.
In Visual Studio 2005, a solution is a thin wrapper that contains a project or a number of projects. In earlier versions of Visual Studio, every project was part of a solution by default. In Visual Studio 2005, some project types can create a temporary solution for you. The solution concept is important because much of what you can do in Visual Studio 2005 revolves around accessing functionality that's exposed in different projects.
Solutions can contain solution items and miscellaneous files in addition to projects. Solutions can also contain Solution Folders, which allow you to group related projects. Solution items can consist of HTML files, bitmaps, icons, XML files, templates, schemas, and others. Miscellaneous files can be a bit of a mystery. First of all, you need to make the Miscellaneous Files folder visible in Solution Explorer to take advantage of these kinds of files. To see this folder, select the Show Miscellaneous Files In Solution Explorer check box on the Documents page in the Environment folder of the Options dialog box, as shown in Figure 2-2. Keep in mind that you won't see the Miscellaneous Files folder until you open a non-project item in the IDE by using File.OpenFile.
Miscellaneous files are files that you might open in the IDE for reference purposes—for example, if you want to review some code in a listing that you don't want to make part of your project. Opening such a file in the IDE without importing it into your solution automatically places the file into the Miscellaneous Files folder. The linked file is aggregated into the Miscellaneous Files folder in a solution.
Keep in mind that any file you open from Visual Studio 2005 gets a link in the Miscellaneous Files folder. This folder persists your items between sessions if you set Miscellaneous Files Project Saves Last to five items or so. This means that you can open specifications, schedules, and notes and have those files at your fingertips every time you open your project, as shown in Figure 2-3.
The Solution Property Pages dialog box gives you easy access to the settings that apply to an entire solution. Among the options that you can control are the startup project or projects for your solution, the locations for files and symbols used for debugging, and the configuration settings that apply to the different projects in your solution.
To get to the Solution Property Pages dialog box, make sure that the solution name is selected in Solution Explorer, press Ctrl+Alt+A, and type Project.Properties in the Command Window. Another way is to right-click the solution and choose Properties. Most of the major programming projects in Visual Studio 2005 present you with the Property Pages dialog box, shown in Figure 2-4.
Clicking the Common Properties folder in the folder pane on the left exposes a number of options. The first option is Startup Project. In multiple-project solutions, you can select the project that launches when the solution is run from the Debug menu. You'll most often set this option on the fly by right-clicking a project name in Solution Explorer and then choosing Set As StartUp Project from the project shortcut menu.
If you want to run more than one project when you choose Start or Start Without Debugging from the Debug menu, select the Multiple Startup Projects option. Selecting this option lets you select the behavior of each of the projects in your solution when you invoke Debug.Start or Debug.StartWithoutDebugging. You can select Start, Start Without Debugging, or None. You can use the Move Up and Move Down buttons to the right of the list of projects to set the order in which the programs are started.
In a number of cases, running multiple projects concurrently might be useful. You might want to test some interprocess communication features between various assemblies in your solution. You might use a second project to do some profiling or instrumentation. Another use might be to run a utility that takes control of another assembly for automated testing purposes.
The second option in the Common Properties folder is Project Dependencies. When some assemblies in a solution depend on others in the same solution, the build order for the different projects in the solution is critical. The Project Dependencies settings let you specify which projects need to be built before others to get the entire solution up and running.
The last option in the Common Properties folder lets you set file paths for source files and debug symbols that might come up in your application. These settings allow you to step into the source code for libraries that are referenced by your projects but aren't part of your project. If you're debugging a project that's referencing a debug version of a .NET assembly, Visual Studio 2005 is usually able to find the source for the assembly if it's available. If the source is stored in a different location, you can specify the location of the source files and the debug symbols so that you can debug into that source.
Solutions can have multiple configurations that give you quick access to preset options that are related to your solution. The Debug and Release configurations are available to new projects by default, but you can create your own configurations by using Configuration Manager, which is accessible from the Solution Property Pages dialog box or from the Build menu (Build.ConfigurationManager).
Visual Studio 2005 offers two types of configurations: solution configurations and project configurations. Solution configurations are for configuring different build setups within a particular solution. For example, you can create and save a specific solution that allows you to select a different configuration for each project in your solution.
The second type of configuration is the project configuration. We'll discuss custom project configurations in detail later in the chapter, but for now, consider how different projects might relate to one another in a solution. Project configurations let you change some very specific build characteristics. These characteristics include code optimizations, debugging switches, and even the location of the project's compiled files. If you have five projects with different custom settings in a single solution, you should use custom solution configurations to save and manage different build options for your assemblies.
The solution source .sln file is a plain-text document that describes the solution. The solution file contains links to the projects contained in the solution. It also contains version information about the format of the solution file itself.
Important
Once you convert a file to Visual Studio 2005, you can no longer open it in earlier versions of Visual Studio.
The .sln file also contains information on the various configurations that have been set up in the solution. Information about the different solution configurations is stored in this file, along with information about how the different project configurations are organized in those solution configurations.
If you take a look at an .sln file in which solution items have been enabled and added, you'll notice that there's no information about these files. Solution items are considered user items, so links to these files are stored in the solution user options (.suo) file. If you pass a folder containing an .sln and an .suo file to another user on another machine, much of the information in the .suo file will become useless to the second user and will be ignored.
Some important items are stored in the .suo file that you can share with another person. Breakpoints that you set in your solution are stored in the .suo file, as are tasks that have been added to the Task List window. If you want to share that information with the person you're sharing the solution with, you should be sure to keep the .suo file in the same folder as the .sln file. If you don't need to share such information, we recommend deleting the .suo file because that file can contain personal and confidential data such as the paths to network shares and even your e-mail alias.
Projects are the second type of container used in Visual Studio. Projects are used to maintain the source files associated with individual assemblies, Web sites and services, and applications. As with solutions, Solution Explorer is the primary tool for managing projects in Visual Studio.
Projects in Visual Studio 2005 consist primarily of file items. These items can be links to files or source files in the same folder as the project file. Whether an item is a link or an actual file depends on the type of project that you're working with. The files associated with Visual C++ projects are links displayed in Solution Explorer. These files are usually in the same folder as the projects. Deleting a link to a file in a Visual C++ project doesn't necessarily delete the file that's opened by the link. It's a rather fine distinction, but if you've ever moved a Visual C++ project and found yourself missing a project file, it might be that the file existed outside the project folder. In Visual Studio 2005, Show All Files now works in Visual C++ to show you all the files located in the physical directory.
.NET Windows projects can consist of a mix of links and actual file items. Web sites are generally contained in a solution but don't have a project file. Table 2-1 shows the possible relationships between project type and file items in Visual Studio 2005.
Table 2-1. Project Items in Visual Studio 2005
Project Type | Associated Items |
|---|---|
Visual C++ | Links to items |
Web site | Items in the Web folder |
Visual Basic | Links and actual items |
Visual C# | Links and actual items |
Visual J# | Links and actual items |
If you take a look at Solution Explorer for a Windows application written in Visual C# or Visual Basic, you can see the mix of project items and file structure items by using Project.ShowAllFiles. Files that are part of the project will appear normally. Files that are not part of the project but are in the project folder will appear slightly grayed. The ShowAllFiles command is available from the Project menu and through toolbar buttons in Solution Explorer. In addition, you'll see a number of files that are kept hidden from the user by default. These hidden files include some types of configuration files and the code-behind files used in ASP.NET applications. In Figure 2-5 most of the items in the project shown are project items.
In addition to the items, a project file stores the configuration metadata associated with the project. Information stored includes configuration data that you specify in the IDE as well as build and debugging data. The nature of this data differs from project type to project type. The compilers for the different languages are written by different teams, so the available options differ from language to language.
You set the options for a project in the Properties window. (In Solution Explorer, right-click a project and choose Properties from the shortcut menu.) The Properties window contains options that you would otherwise have to specify at a command prompt when compiling a project; these settings match particular command-line options.
Considering the four major languages that ship with Visual Studio and the different types of projects that you can create, there are quite a few compiler options. This is where project configuration in Visual Studio becomes fun. By creating custom project configurations, you can try out many different types of builds and save those configurations for future use and reference.
You can access the Configuration Manager dialog box by entering Build.ConfigurationManager in the Command Window. To create a new project configuration, click the drop-down button adjacent to the desired project in the Configuration column of the Project Contexts grid and then click New. The New Project Configuration dialog box appears (shown in Figure 2-6).
Give your new configuration a name, and set the base settings for the configuration by selecting an existing configuration from the Copy Settings From drop-down list. As with the New Solution Configuration dialog box, you can create a new solution configuration automatically to match your new project configuration by selecting the Create New Project Configurations check box. At this point, you should be ready to experiment with some settings in your project. Just create a new test configuration that you can experiment with and leave all the default settings in the two default configurations.
Properties for managed applications written in Visual Basic, Visual C#, and Visual J# all display somewhat similar layouts in the Properties window. When creating a Web application, you can change project settings through that project's Properties dialog box.
Figure 2-7 shows the Application tab for a Visual Basic Windows application.
The Configuration list for a project can be found on a number of the tabs in the Properties window. You can use this drop-down list to experiment with settings and save them as separate build types. You can easily create and save new build types for almost any kind of Visual Studio 2005 project and compile them from inside the IDE.
In this section, we'll point out a few of the important settings in the Properties window for a Visual C# project. You can get to most of these settings in a Visual Basic project, as well.
Figure 2-8 shows the Build page from the Configuration Properties folder for a Visual C# project. You can save any of these settings to a custom build type. One of the most useful settings for configuring a custom build type is the output path. The default output path for a Visual C# Debug build is inDebug. The release build is inRelease by default. When you create a custom build type, you get one of these two paths, depending on which type of build you get your initial settings from. If you're creating a custom build, it might make sense to copy the output of that build to a new folder so that you can compare the output assemblies. For cases like this, you can create a new build path to match your build name. For example, if you have a build named DebugOverflow (to indicate that you've enabled overflow checks for this build type), you can change the output to inDebugOverflow.
The Debug page, shown in Figure 2-9 can be especially useful when you're building class library, Windows, and Web services projects. You can experiment with a lot of settings on this page, but one of the most useful to our discussion is the Start Action option. Using different build types, you can specify particular URLs that you want to test your Web service against. You can use the Start Action option in the same way to test your libraries. It lets you easily debug your service or library against a number of test applications.
The Property Pages dialog box for Visual C++ projects has a huge number of settings because of the large number of compile and link options available. The custom build options that we've talked about in this chapter apply to Visual C++ as well. In fact, because of the many properties available, you should find custom settings for unmanaged projects very useful, especially in testing and teaching situations.
Figure 2-10 shows the Property Pages dialog box for a Visual C++ Win32® project.
The Property Pages dialog box for a Visual C++ project has a number of subfolders under the Configuration Properties folder. Table 2-2 contains a list of some of these folders and the general property types that you can set from each. If you're an experienced Visual C++ programmer, you'll find most of these settings fairly straightforward.
Table 2-2. Selected Configuration Properties Subfolders in Visual C++
The Build Events node allows you to do a few interesting things with your custom builds. You can see the Post-Build Event page in Figure 2-11. If you're working with multiple projects and builds, you can use the Build Events folder to run applications and scripts during your build process. In this case, we've added a call to Regsvr32.exe as the command line for the Post-Build Event in the project. After this project is built under this configuration, the target file is registered with Windows.
Project source files have different extensions based on the language specific to the project. Table 2-3 lists the project types and extensions that they hold.
Visual Basic, Visual C#, and Visual J# projects also contain user option files. These files take the form ProjectName.ProjectExt.user. A Visual Basic user options file has the extension .vbroj.user. These project user files are in XML and contain information specific to the custom builds that you've created. Unlike the binary .suo file, the .user files are intrinsic to custom build types and should usually be kept with a project.
If you're building complex solutions that contain a number of assemblies with interproject dependencies, you can take advantage of Solution Explorer to help you manage these dependencies. Solution Explorer makes it really easy to add file, project, and Web references to your projects. For solutions with dependencies between projects, you'll want to use project references.
To add a project reference, open the Add Reference dialog box by selecting a project in Solution Explorer and typing Project.AddReference in the Command Window. On the Projects tab, you'll see a list of the projects in your solution, as shown in Figure 2-12.
After you add a project reference, the functionality available from the referenced project becomes available to the project adding the reference. At this point, build order becomes important because the referenced assembly must be built before the project that references it. To help you manage dependencies such as this, Visual Studio provides a Project Dependencies dialog box (Projects.ProjectDependencies), as shown in Figure 2-13. This dialog box lets you specify a dependency, and it then changes the build order of affected projects in a solution accordingly.
Once the projects, custom build configurations, and references are set in a solution, you can begin to work out the build scenarios that you want to run with the different configurations. To specify which projects in the solution should be built, you can use the Configuration Manager dialog box (shown in Figure 2-14). You can easily exclude projects that might give you problems, or you can simply save some time when you want to concentrate on a specific build in a solution.
There's one more powerful build dialog box you can use to build multiple configurations at one time. The Batch Build dialog box (Project.BatchBuild), shown in Figure 2-15, is helpful for building multiple projects with different configurations, but it's not available for every application type.
The Batch Build dialog box lets you perform a number of important actions, including building, rebuilding, and cleaning your projects. Clicking the Build button initiates an incremental build for projects that are configured for such a build. The Rebuild button initiates a Rebuild All for all the selected projects. Clicking the Clean button deletes the files that are output by a build so that you can restart the build cleanly or share your projects without unnecessary bulk.
Although the project management facilities in Visual Studio are formidable, the usability of the IDE for developers also relies on the editor features in the IDE. In Chapter 3, we'll discuss the code editor in detail and discuss techniques that can help you become more productive as you write code.