Projects
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.
Project Items
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.
| 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.
Figure 2-5: Link and files in a Visual C# solution
Project Properties
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.
Saving a Custom Configuration
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).
Figure 2-6: The New Project Configuration dialog box
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.
Figure 2-7: The Application tab for a Visual Basic Windows application
Configuration Properties
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 \bin\Debug\. The release build is \bin\Release\ 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 \bin\DebugOverflow.
Figure 2-8: The Build page for a Visual C# Windows Forms application
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.
Figure 2-9: The Debugging page for a Web application
Visual C++ Projects
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.
Figure 2-10: A custom configuration in Visual C++
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.
| Subfolder | Properties |
|---|---|
| General | Specify output directories, log options, MFC/ATL options, CLR support (/CLR). |
| Debugging | Specify which debugger you want to use from the IDE. These include the local debugger, remote debugger, or other debugger. |
| C/C++ | Compiler options, preprocessor definitions, paths to some output files, and command-line compile options. |
| Linker | Link options, debug options, and command-line link options. |
| Resources | Resource file name and path, culture, and resource compiler command line. |
| Browse Information | Options relating to BSCMAKE (browser files). |
| Build Events | Commands that you can run during the build process. |
| Custom Build Step | Properties for configuring an additional task you specify when building a file or a project. For example, you might pass an input file to a tool that returns an output file. |
| Web Deployment | Specifies how a Web deployment tool will install your application. |
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.
Figure 2-11: Build events let you run applications during your build process
Project Source Files
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.
| Project Type | Extension |
|---|---|
| Visual Basic | .vbproj |
| Visual C# | .csproj |
| Visual C++ | .vcproj |
| Visual J# | .vjproj |
| Deployment | .vdproj |
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.
Project Dependencies
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.
Figure 2-12: Adding a project reference to a project in a solution
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.
Figure 2-13: Configuring build dependencies for a project
EAN: 2147483647
Pages: 100