Working with Projects
As source code containers, projects principally act as a settings applicator. They are used to control and organize your source code files and the various properties associated with the whole build and compile process. (You learn about the build process in depth in Chapter 11, “Deploying Code.”) As with solutions, projects can contain various items that are germane to their development. Projects are language specific. You cannot mix different languages within a specific project. There is no similar limitation with solutions: a solution can contain many projects, each one in a different language.
Project Items
After a project is created, by default it contains one or more project items. These default items vary depending on the project template you selected and on the language of the project. For instance, creating a project using the C# Windows Forms application template results in the formation of a Form1.cs file, a Form1.Designer.cs file, and a Program.cs file. Projects are also preconfigured with references and properties that make sense for the given project type: the Windows Forms application template contains a reference to the System.Windows.Forms assembly, whereas the class library template does not.
Projects, like solutions, can have subfolders within them that you can use to better manage and group project items. Unlike solutions, the folders you create within a project are physical; they are created on disk within your project directory structure. These are examples of physical project items. Source code files are also physical in nature.
Projects can contain virtual items (items that are merely pointers or links to items that don’t actually manifest themselves physically within your project structure). They are, for example, references to other assemblies, database connections, and virtual folders. (Virtual folders are described in Chapter 5.) Figure 4.13 illustrates a fully described solution and project.
Project Properties
Like solution properties, project properties are viewed and set using a series of property pages accessed through the Project, Properties menu. These property pages are hosted within a dialog box referred to as the Project Designer. Figure 4.14 shows the Project Designer that is displayed for a sample Visual Basic class library project. Different languages and different project types actually surface different property pages within the Project Designer. For instance, the Application property page for a Visual Basic project looks different and contains slightly different information than an identical Visual C# project (although the basic intent of the page remains unchanged).
In general, you use project properties to control the following:
General project attributes such as the assembly name and project type
The way the project is built/compiled
Debugger configuration for the project
Resources used by the project
Signing and security settings
Note
The Project Designer is easily accessed from the Solution Explorer pane. For C# projects, you can double-click the Properties item under the project. Visual Basic projects have a My Project item that does the same thing. And, of course, you can always right-click the project name and then select Properties from the pop-up menu.
Let’s examine some of the more common project property pages and discuss briefly the options that can be set on each.
Application
The Application property page allows you to set the assembly name, root/default namespace, application/output type, and startup object. For Windows Forms applications, authentication modes and visual styles are also controlled via this property page. Note that the options available in this dialog depend on the project type and the chosen language:
Assembly Name—This is the filename of the assembly that the project is compiled into. Typically, it defaults to the project name. The extension used is determined by the output type of the project.
Target Framework—This is the specific version of the .NET Framework to be targeted by the project. Starting with Visual Studio 2012, options were added here for .NET Framework 4.5, but you can continue to compile code against earlier versions from 2.0 onward.
Root/Default Namespace—This specifies a namespace to be used by any types declared within the project. This can also be declared manually in code.
Output Type (C#)/Application Type (VB)—This value determines the fundamental project type (for example, class library, Windows application, console application).
Startup Object—This object is used to set the entry point for the project. For Windows Forms applications, this is the default form (or in the case of C#, the class and entry point method—Program.Main by default when [Not Set] is selected) that should be launched when the application is executed. For console applications, the startup object is the method that Windows calls after the console has been created—also Program.Main by default when (Not Set) is selected. Class library projects do not have an entry point and will be set to (Not Set) for C# projects, and (None) for Visual Basic projects.
Icon—This is the icon to associate with the assembly and visible from the Windows Explorer. It is not pertinent to class library or web projects.
Resource File—This text box can be used to specify a path and filename for a Win32 resource file. Resource files contain nonexecutable content, such as strings, images, or version information, that is embedded within the compiled assembly. Note that by default for .NET projects, version information is generated based on the AssemblyInfo file that contains specific attributes.
Windows Application Framework Properties—Visual Basic provides a series of properties that apply specifically to Windows application projects. These properties allow you to set the splash screen associated with the project, enable or disable support for XP themes/visual styles, set the authentication mode supported by the project (Windows or application-defined), and set the shutdown mode of the project. The shutdown mode specifies whether the application should shut down when the initial form is closed or when the last loaded form in the application is closed.
Build (C# Only)
The Build property page is used with Visual C# projects to tweak settings associated with build configurations. Using this dialog box, you can select whether the DEBUG and TRACE constants are turned on, and you can specify conditional compilation symbols. Settings that affect the warning and error levels and the build output are also housed here. For more exploration of the options available here, see Chapter 10.
Build Events (C# Only)
Visual Studio triggers a prebuild and postbuild event for each project. On the Build Events page, you can specify commands that should be run during either of these events. This page also allows you to indicate when the post-build event runs: always, after a successful build, or when the build updates the project output. Build events are particularly useful for launching system tests and unit tests against a project that has just been recompiled. If you launch a suite of, say, unit tests from within the postbuild event, the test cycle can be embedded within the build cycle.
Note
If you specify commands in the prebuild or postbuild events, Visual Studio creates a batch file for each event and places it into the bin/debug directory. These files, PreBuildEvent.bat and PostBuildEvent.bat, house the commands you enter on the Build Events property page. In the event of an error running the build event commands, you can manually inspect and run these files to try to chase down the bug.
Compile (VB Only
The Compile property page is used by Visual Basic projects to control which optimizations are performed during compile and control general compilation options for the output path and warnings versus errors raised during the compilation process. It is analogous to the C# Build property page:
Compile Options—You use the Option Strict, Option Explicit, and Option Infer drop-downs to turn on or off these settings. You can also control whether the project performs binary or text comparisons with the Option Compare drop-down.
Compiler Conditions—Visual Basic allows you to customize the level of notification provided upon detecting any of a handful of conditions during the compilation process. For instance, one condition defined is Unused Local Variable. If this condition is detected in the source code during the compile, you can elect to have it treated as a warning or an error or to have it ignored altogether.
Build Events—Visual Basic allows you to access the Build Events property page (see the preceding section for an explanation) via a Build Events button located on this screen.
Warning configurations—You can choose to disable all compiler warnings, treat all warnings as errors, and generate an XML documentation file during the compile process. This results in an XML file with the same name as the project; it contains all the code comments parsed out of your source code in a predefined format.
Start Action—You use this option to specify whether a custom program, a URL, or the current project itself should be started when the debugger is launched.
Start Options—You use this option to specify command-line arguments to pass to the running project, set the working directory for the project, and debug a process on a remote machine.
Enable Debuggers—You use the check boxes in this section to enable or disable such things as support for debugging unmanaged code, support for SQL stored procedure debugging, and use of Visual Studio as a host for the debugger process.
Publish
The Publish property page enables you to configure many ClickOnce-specific properties. You can specify the publish location for the application, the install location (if different from the publish location), and the various installation settings, including prerequisites and update options. You can also control the versioning scheme for the published assemblies.
References (VB Only)
The References property page is used within Visual Basic projects to select the assemblies referenced by the project and to import namespaces into the project. This screen also allows you to query the project in an attempt to determine whether some existing references are unused. You do this by using the Unused References button.
Reference Paths (C# Only)
The Reference Paths property page allows you to provide path information meant to help Visual Studio find assemblies referenced by the project. Visual Studio first attempts to resolve assembly references by looking in the current project directory. If the assembly is not found there, the paths provided on this property page are used to search for the assemblies. Visual Studio also probes the project’s obj directory, but only after attempting to resolve first using the reference paths you have specified on this screen.
Resources
Resources are items such as strings, images, icons, audio, and files that are embedded in a project and used during design and runtime. The Resources property page allows you to add, edit, and delete resources associated with the project.
Security
For ClickOnce applications, the Security property page allows you to enforce code access security permissions for running the ClickOnce application. Various full-trust and partial-trust scenarios are supported.
Settings
Application settings are dynamically specified name/value pairs that can be used to store information specific to your project/application. The Settings property page allows you to add, edit, and delete these name/value pairs.
Each setting can be automatically scoped to the application or to the user and can have a default value specified. Applications can then consume these settings at runtime.
Signing
The Signing property page allows you to have Visual Studio code sign the project assembly (and its ClickOnce manifests) by specifying a key file. You can also enable Delay Signing from this screen.