Visual Studio is all about projects and solutions. It's essential that you understand the differences between them, and get comfortable with using them.
A large part of working with Visual Studio is the management of solutions and projects. Nothing can hamper a project more than a poorly designed solution or project structure. In this hack, you will learn how to work with and configure solutions and projects.
|
Solutions are Visual Studio's highest level of organization. They collect any number of projects together under one manageable structure. Solutions store information about the contained projects, including project dependencies and build order, and can also contain miscellaneous solution items. Solution files have a few limitations. Only a single solution can be opened in an instance of Visual Studio at a time, and solution files cannot contain other solution files. Projects, however, can be members of multiple solutions. This allows you to create a number of solutions for different purposes that make use of the same projects. (An example of this is business entities or interfaces that you need to share across client and server solutions.)
A solution is
automatically
created when you create a new project, but you can also create a
blank solution without creating a project. To create a new blank
solution, click on File
There are two types of solution settings: settings that are saved in the solution file (.sln extension) [Hack #4] and apply to all users of the solution, and settings that are saved in the solution user options file (.suo extension). The user options file is not shared between users and will apply only to the user who sets them. You can control a number of configuration settings at the solution level, including the startup project, project dependencies/build order, and build configuration:
The only purpose of the startup project settings is to configure what project Visual Studio should execute when you start the debugger. This setting has no impact on your actual application. The startup project will usually be one of the following kinds of projects:
Starts an instance of Internet Explorer and loads your web project
Launches an instance of your Windows Forms application
Launches your application in the console
You cannot set a class library, or any project without an executable output, to be the startup project. The startup project setting is stored at the user level in the solution user options file, which gives different users the ability to set up different startup projects. This also means that the startup project setting will not be transferred between users.
Visual Studio 2005 adds the ability to create multiple startup projects and lets you configure whether each project should be started in debug mode. The Visual Studio 2005 Startup Project property page, accessed by right-clicking on the solution in the Solution Explorer and choosing Set Startup Projects from the menu, is shown in Figure 1-1.
Project dependencies dictate the build order of your projects. Project dependencies are normally inferred from project references. If Project A references Project B, then Visual Studio knows that Project B must be built before Project A can be built. There are times when you will need to manually set project dependencies; for such cases, use the Project Dependencies dialog to set which projects are dependent on other projects:
First, right-click on the solution and click the Project Dependencies item. You will see this option only if you have more than one project in your solution.
Next, choose the project you want to create a dependency for and check the box next to the project that this project is dependent on. In Figure 1-2, I have specified that the HacksWinApp project depends on the HacksLib project.
As you can see in Figure 1-3, Visual Studio appropriately sets the build order to build HacksLib first and then build HacksWinApp.
Build settings are stored at both the project and solution level. The build settings for an individual project are stored in that project file. These settings define what the debug or release mode for a project should do. The build settings that are defined at the solution level simply define in what mode each of the projects in a solution should be built. By default, each project and solution contains a debug and release configuration. By selecting either the debug or release configuration at the solution level, the solution will build each of the projects with the corresponding project configurations. All of these settings are configured through the Configuration Manager, which can be seen in Figure 1-4.
The drop-down at the top is the solution configuration. In Figure 1-4, the selected solution configuration is Debug. You can see that, for this configuration, Visual Studio will build both of the projects with their respective debug configurations.
You can also create new configuration modes from the Configuration Manager. You might want to create a configuration that builds the HacksLib project in release mode but builds HacksWinApp in debug mode. To do this, you first need to select New from the drop-down at the top of the Configuration Manager. Next, you need to name your new solution configuration in the New Solution Configuration dialog shown in Figure 1-5.
After specifying your new configuration name, select which current configuration to copy the current settings from. This is a timesaving feature that allows you to avoid starting from scratch. The checkbox specifies whether you want to also create new project configurations. In this example, you are going to use the default debug and release configurations, so you don't need to create any new project configurations, which will be discussed under "Project settings," later in this hack. Uncheck this checkbox. After clicking the OK button, you will see your new configuration in the Configuration Manager. You can then configure the HacksLib project to be built in release mode and the HacksWinApp project to be built in debug mode or any other combination that you wish.
Solution ItemsSolutions normally contain only projects, but you can also add miscellaneous items to your solutions. These items must be files that you don't want to be compiled. This could be project documentation, Visio documents, stylesheets, or any other documents that might not be directly linked to a particular project but relevant to the entire solution. You can even include code files (.vb, .cs, etc.). They won't be compiled, but if you wanted to include examples, this would be a perfect place. To add a solution item, you simply need to right-click on the
solution file and choose Add |
Projects are one of the most important parts of working with Visual Studio. Projects contain any number of source files that are compiled into some kind of output. The output could be a Windows Forms executable, console application, class library, or any number of various outputs. There are different projects for different languages including C++, C#, VB.NET, and more. There are also special purpose projects like the setup project and the database project [Hack #74] . Overall, Visual Studio contains more than 90 different project types. This number varies based on your installation settings and increases if you install add-ins or language services because they often create even more project types.
When creating a
project,
you will either be creating a new project from scratch or adding a
project to an existing solution. To create a new project from
scratch, click on File
|
From this dialog, you can select the type of project that you would like to create. You can also name your project and specify where the project and project files should be stored. Once you have created a project, you can then configure that project.
Visual Studio 2005 adds additional functionality to this dialog by way of an option that allows you to download templates from the Internet. Using this functionality, you can download project templates, item templates, code snippets, and samples from the Internet and quickly add them to your copy of Visual Studio.
A number of settings can be configured at the project level. I will continue with the example from the solution configurations section in which I created a TestBuild solution configuration that built one project in release mode and the other project in debug mode. My requirements might change, and instead of building the HacksLib project in release mode, I want to create a custom configuration for the project that optimizes the code but also includes debug information. There is no default configuration that optimizes code and includes debug information, so you will need to create a custom configuration. To do this:
Go back to the same Configuration Manager used in the solution configuration section and shown in Figure 1-4.
To create a new project configuration, select New from the list of existing project configurations. You are then shown the New Project Configuration dialog, which is shown in Figure 1-7.
Name your new project configuration and then select from which current configuration you want to copy the settings. In this case, you can name your configuration TestBuild and copy the current settings from the debug configuration. Since you already created a solution configuration called TestBuild, you can uncheck the checkbox that would normally create this solution configuration automatically for you.
After the project configuration is created, you can access it in the normal project property pages and adjust your settings. Figure 1-8 shows this property page for C Projects.
I am not going to go into each of the individual properties here. You can select properties in the Configuration Manager and see a brief description of the property in the bottom of the pane as well as what compiler option that property corresponds to.
Figure 1-9 shows the property page for VB.NET Projects, which is a little different than the property page for C#.
Visual Studio 2005 introduces the idea of temporary projects for managed language projects in which the IDE does not save any project files until you tell it to save the files. This is different than Visual Studio .NET 2002 and 2003 in which the project files are saved as soon as you create a new project. (This probably led you to creating lots of little projects that you never touched again, just to try out something. This is known as the WindowApplication21 syndrome.)
To enable this feature, you will need to ensure that the checkbox
titled "Save new projects when
created" in Tools
Visual Studio 2005 keeps the project and solution files as temporary files while you are working with the unsaved project. As of this writing, the Visual Studio 2005 beta uses the C:\Documents and Settings\<Username>\Local Settings\Application Data\Zero Impact Projects directory to hold these files, but this is subject to change.
Visual
Studio 2005 includes another
new feature that allows you to configure Visual Studio to
automatically save your projects and solutions
and then recover them in the event of a crash
of the IDE. To configure this functionality, go to Tools
Using this dialog, you can configure how often your information should be saved and how long that recovery information should be stored. If Visual Studio crashes, you will be prompted to have Visual Studio automatically restore your project or solution when the IDE is restarted.