Professional Visual Studio 2005 (2006) [eng]

Chapter 8

Figure 8-10

Workspaces

The source control interface provided by Team Foundation uses a concept called a workspace. A workspace is simply a location on the local computer where files are placed when they are retrieved from the server. Whereas SourceSafe supports only a single mapping between the folder structure within the repository to a directory on the local computer, Team Foundation supports any number of workspaces.

Most developers use only a single workspace for any given project. However, an additional workspace can be useful if you are working on a new piece of functionality that is not complete and have to change tasks to fix a bug. Instead of putting the changes to one side a developer can switch to a different workspace, fix a bug, check in the changes, and then return to the original workspace.

Pending Changes

Visual SourceSafe uses the Pending Changes window to list files that have been checked out. As Team Foundation provides additional functionality when files are checked into the repository, it makes use of a new window also called Pending Changes. This window is divided into four vertical tabs that are used to associate additional data with the files being checked in:

Source Files

Work Items

Check-in Notes

Policy Warnings

Source Files

The Source Files tab (see Figure 8-11) shows the list of source files waiting to be checked in. This is similar to the Pending Changes window used by SourceSafe. It allows comments to be appended to a file being checked in, as well as provides an interface for rolling back any unwanted changes.

Figure 8-11

106

Source Control

Work Items

The Work Items tab (see Figure 8-12) provides a list of outstanding tasks being tracked by the Team Foundation Server. When the tab is first selected, a query is run against the server and the list of tasks is retrieved. Changes being checked in can be assigned to a particular work item, providing information about what issue or functionality the change was addressing. As part of this process, the work item state can also be changed from Active to Resolved if appropriate.

Figure 8-12

Check-in Notes

Prior to a set of changes being checked in, the changes may have to be reviewed by a number of parties. In this case, the Check-in Notes tab (see Figure 8-13) provides space for comments to be added by a Code, Security, and Performance reviewer. These notes will also be associated with the changes for future reference.

Figure 8-13

Policy Warnings

The last tab, Policy Warnings (see Figure 8-14), provides information about any policies that are currently being violated. In addition to providing a mechanism for tracking changes and work items, Team Foundation also provides some process guidance. One area where this can be applied is when files are checked in. Policies can be established that require each check in to be associated with a work item or to be reviewed prior to check in.

107

Chapter 8

Figure 8-14

Shelving

The other area in which Team Foundation makes a significant improvement over SourceSafe is its ability to shelve changes. Quite often a developer will be working on one task and need to put those changes to one side while they do something else. Alternatively, they may need to hand a task over to someone else to complete it, or even for review and testing prior to being checked in. In each of these scenarios, shelving the changes into the source repository enables those changes to be retrieved at a later stage, perhaps by someone else, for work to continue.

Shelving changes can be done the same way as checking in changes — via either the Solution Explorer or the Source Control Explorer. When the Shelve Pending Changes item is selected, the Shelve – Source Files dialog appears, as illustrated in Figure 8-15. As per the check-in process, it is possible to associate work items and check-in comments with the change set.

Figure 8-15

These changes can be retrieved from the repository via the Unshelve Pending Changes menu item. As there may be multiple change sets waiting to be unshelved, you will have to select the correct one to retrieve. To determine the appropriate change set, select the Details option to show the work items and check-in comments made when the change set was shelved. After unshelving, the files with changes will be shown in the Pending Changes window.

108

Source Control

Summar y

This chapter demonstrated Visual Studio 2005’s rich interface for using a source control repository to manage files associated with an application. Checking files in and out can be done using the Solution Explorer window, and more advanced functionality is available via the Pending Changes window.

You have also seen some of the advantages that a more enterprise-ready source control repository, such as Team Foundation, provides. While SourceSafe is sufficient for small teams of developers, it has not been designed to scale for a large number of developers. Nor does it have the capability to track tasks or reviewer comments against a set of changes.

109

Application

Configuration Files

One of the challenges of building applications is being able to adjust the way the application functions on-the-fly without having to rebuild it. There has been a long history of applications using configuration files to control the way an application runs. .NET applications use a series of XML configuration files that can be adjusted to determine application behavior. This chapter explores the structure of these configuration files and demonstrates how you can store custom information using a configuration section handler.

Config Files

The .NET Framework configuration system consists of several configuration files (discussed in the following sections) that can be used to adjust one or more applications on a computer system. Part of this system is an inheritance model that ensures that configurations can be applied at the appropriate level.

Machine.config

At the root of the inheritance model is the machine.config file (located in the systemroot\ Microsoft .NET\Framework\versionNumber\CONFIG\ folder), which defines configuration settings for the entire system. All configuration files inherit from this file and can override these settings.

Web.config

Web applications are configured via the web.config file. This file can be located in a number of locations depending on the scope to which the settings need to be applied. To apply a configuration to all web applications on a machine, place the web.config file in the same directory as the

Chapter 9

machine.config file. In most cases the settings need to be applied at a much finer granularity. As such, the web.config file can also be placed in any virtual directory or subdirectory to control web applications at that level. If placed in the root folder for a web site, the configuration will be applied to all ASP.NET applications in that web site.

A word of caution: When you are working with virtual directories that do not align with the directory model on the computer, it is possible to have an application with different configurations depending on how it is referenced. For example, consider c:\inetpub\wwwroot\MainApplication\Contacts\ Contact.aspx, which has been set up with both MainApplication and Contacts as virtual directories. You can reference the contact page as either

http://localhost/MainApplication/Contacts/Contact.aspx

or

http://localhost/Contacts/Contact.aspx

In the first case, the configuration settings that are applied are inherited from the MainApplication folder and may be overridden by a configuration file in the Contacts folder. However, in the second case, settings are applied only from the configuration file within the Contacts folder.

App.config

Windows applications can be configured using an application configuration file, which also inherits from machine.config. As the output assembly name is known only when an application is compiled, this file starts off as app.config and is renamed to <application>.exe.config as part of the build process. For example, an application with AccountingApplication.exe as the main executable would have a configuration file entitled AccountingApplication.exe.config. This configuration file is automatically loaded based on its name when the application is loaded.

Security.config

In conjunction with the application configuration files are a number of security configuration files. These also follow an inheritance path but across a different dimension. Instead of being application focused, the security configuration files are broken down into Enterprise (Enterprisesec.config), Machine (Security.config), and User (Security.config). The Enterpriseand Machine-level files are both stored in the same location as the machine.config file, while the User-level file is stored under the user-specific application data folder.

Configuration Schema

A configuration file, whether it is a machine.config, web.config, or an application configuration file, needs to adhere to the configuration schema that determines which elements should be included. The schema can be found at C:\Program Files\Microsoft Visual Studio 8\Xml\Schemas\ DotNetConfig.xsd and is broken down into a number of sections.

112

Application Configuration Files

Configuration Attributes

All configuration elements can specify a configSource, which is simply a redirection to a separate file. This can be useful if a configuration file becomes unwieldy in length. The following code snippet illustrates how a section of a configuration file can be extracted and subsequently referenced using this attribute:

<!-- Original Configuration Section --> <WindowsApplication1.My.MySettings”>

<setting name=”Button1_Text” serializeAs=”String”> <value>Press Me!</value>

</setting>

</WindowsApplication1.My.MySettings>

<!-- Reduced Configuration Section using configSource -->

<WindowsApplication1.My.MySettings configSource=”MySettings.Config” /> <!-- Code from MySettings.Config --> <WindowsApplication1.My.MySettings”>

<setting name=”Button1_Text” serializeAs=”String”> <value>Press Me!</value>

</setting>

</WindowsApplication1.My.MySettings>

Note a couple of limitations in using a configSource:

There is no merging of configuration sections between the referenced file and the original configuration file.

This attribute cannot be applied to configuration section groups. This can be a significant limitation, as the purpose of a section group is to group items that relate similar configuration sections. A logical separation could see all items in a particular section group in a separate configuration file.

Each element within the configuration file inherits a number of attributes that can be set to control whether that element can be overridden or not. To prevent an element, or even an entire section, from being overridden, that item can be locked. To reduce the number of attributes that are applied, five different locking attributes (outlined in the following table) can be used to specify any number of configuration attributes and elements that are to be locked.

Configuration Element	Description
LockItem	Locks the element to which this attribute is applied, including all
	other attributes provided on that element and all child elements
LockAttributes	Locks the comma-delimited list of attributes provided
LockAllAttributesExcept	Locks all attributes except those provided in the comma-delimited
	list
LockElements	Locks the comma-delimited list of child elements provided
LockAllElementsExcept	Locks all child elements except those provided in the comma-
	delimited list

113

Chapter 9

Being able to lock configuration items is particularly relevant to web applications, which might contain a deep hierarchy of configuration inheritance. Windows applications inherit only from the machine

.config file, so it is unlikely that the need will arise to lock items.

Section: startup

The startup configuration section determines the version of the framework that is either required (<requiredRuntime>) or supported (<supportedRuntime>) by the framework. By default, a .NET application will attempt to execute using the same version of the framework on which it was built. Any application being built with support for multiple versions of the framework should indicate this using the supportedRuntime element, defining the most preferred framework version first:

<configuration>

<startup>

<supportedRuntime version=”v2.0.50727”/>

<supportedRuntime version=”v1.1.4322”/> </startup>

</configuration>

This configuration section would be used by an application that has been tested for both version 2.0 and 1.1 of the framework. Anomalies were detected in the testing for version 1.0 of the framework, so this has been omitted from the supportedRuntime list. The version number must correspond exactly to the installation directory for that framework version (for example, version 2.0 of the framework typically installs to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\).

Section: runtime

Garbage collection is a feature of the .NET Framework that distinguishes it from nonmanaged environments. The process of collecting and disposing of unreferenced objects is usually done in parallel with the main application on a separate thread. This means that the user should not see any performance issues due to this process being run. However, there may be circumstances when this is not desirable and this process should be run inline with the main application. The runtime section of the configuration file can be used to provide limited control over how the .NET runtime engine operates. This includes specifying whether the garbage collection should be done concurrently with the main application.

This section can also be used to specify a location in which to search for assemblies that may be required by an application. This attribute can be useful if an application references assemblies. The following code illustrates the use of the codeBase attribute to locate the ImportantAssembly.dll, as well as to dictate that garbage collection be done inline with the main application thread:

<configuration>

<runtime>

<assemblyBinding xmlns=”urn:schemas-microsoft-com:asm.v1”> <dependentAssembly>

<assemblyIdentity name=”ImportantAssembly” publicKeyToken=”32ab4ba45e0a69a1” culture=”neutral” />

<codeBase version=”2.0.0.0” href=”../ImportantAssembly.dll”/> </dependentAssembly>

114

Application Configuration Files

</assemblyBinding> <gcConcurrent enabled=”false”/>

</runtime>

</configuration>

Section: system.runtime.remoting

The remoting section of the configuration file can be used to specify information about remote objects and channels required by the application. For example, the default HTTP channel can be directed to listen to port 8080 using the following configuration snippet:

<configuration>

<system.runtime.remoting>

<application>

<channels>

<channel port=”8080” ref=”http”/> </channels>

</application>

</system.runtime.remoting>

</configuration>

Section: system.net

With the current demand for more secure operating environments, organizations often use proxies to monitor and protect traffic on their networks. This can often result in applications not functioning correctly unless they have been configured to use the appropriate proxy. The networking section of the configuration files can be used to adjust the proxy that is used by an application when making HTTP requests.

Version 2.0 of the .NET Framework ships with an SmtpClient class that can be used to send mail from within an application. Obviously, this requires information such as the server and the credentials to use when sending mail. Although this can be hard-coded within an application, a more flexible approach would be to specify this in a configuration file that can be adjusted when the application is deployed. The following configuration snippet illustrates the use of the default proxy (although it bypasses it for local addresses and the DeveloperNews web site) and specifies the default SMTP settings to be used by the SMTP client:

<configuration>

<system.net>

<defaultProxy>

<proxy usesystemdefaults=”true” proxyaddress=”http://192.168.200.222:3030” bypassonlocal=”true” />

<bypasslist>

<add address=”[a-z]+\.developernews\.com” /> </bypasslist>

</defaultProxy>

<mailSettings>

<smtp deliveryMethod=”network”>

<network host=”smtp.developernews.com” port=”25” defaultCredentials=”true” />

115