• Sidebar: New Web Site Supports Architects
• Illustration: An Example of Visual Studio Policy

Visual Studio .NET (VS.NET) includes two new features to help software architects who lead large development teams to better communicate and enforce their design decisions: Enterprise Templates, which streamline the process of creating new applications, and Development Policy, which allows architects to limit the options available from within VS.NET. Although VS.NET is quite effective at enforcing policy set by architects, creating the templates that define the policy is cumbersome. In addition, the product contains few improvements to source code control—a key component of team development.

Architects Face Challenges

Many corporations rely on their most experienced developers (sometimes called software architects) to define the logical structure of applications and key technologies used in application development—not just for a single application, but consistently across the entire organization and development time frames. For example, an architect might specify that all line-of-business applications will use a common set of Web services to access corporate databases; which applications will be accessed via a Web interface; and which applications will have custom, thick-client interfaces. These specifications serve as blueprints for developers. In addition, many solution providers and consulting firms have architects who define reusable application architectures that developers tailor for specific client requirements.

However, architects face the following challenges in developing and implementing their designs:

A lack of information tailored to architects. Because Microsoft tailors most of its development information for individual developers, software architects struggle to obtain information targeted to their experience level and problems. Microsoft has created a new Web site to help address this problem. (For more information, see the sidebar "New Web Site Supports Architects".)

The "blank slate" problem. Once an architect has developed a set of application guidelines or blueprints for an organization, those guidelines must be communicated to the developers who will implement the actual applications. This communication traditionally is done via application frameworks or methodologies, e-mail, or other written specifications.

But developers still face an intimidating blank slate when they begin to implement those blueprints with Visual Studio. Although Microsoft does include a multitude of wizards and other tools to sketch the outlines of new projects and to easily create project containers and skeleton files, such tools are generic and not specifically tailored to the architecture in use within a given organization. Using the previous example, if an architect specifies that an application should use a Web service to access a database, the developer must still remember to include those components when starting work on a new application.

Too many choices. Finally, individual developers often face a bewildering array of options once an application is under development. For most of the tasks a developer faces, Visual Studio offers multiple solutions, some of which may conflict with the guidelines established by the architect.

In our example, if the architect has specified a set of Web services to be used for database access, the developer must remember not to use the numerous other ways that Visual Studio presents for accessing data, including the seven database components found in the standard Visual Studio toolbox.

Templates and Policy

To help architects better communicate their designs and enforce their decisions, VS.NET includes a set of new features known as Enterprise Templates. An Enterprise Template is set of files that defines the initial structure for an application, along with a set of rules, or a development policy, that limits the options available to the developer implementing the application. Once created, these templates appear in the VS.NET "New Project" dialog box and can be used by developers as the starting point for new applications. VS.NET will enforce the development policy specified by the template.

Both the Enterprise Developer and Enterprise Architect Editions of VS.NET can use Enterprise Templates and enforce development policy, but only the Enterprise Architect Edition of VS.NET can create Enterprise Templates.

Templates Define "Starting Points"

An Enterprise Template is similar to Visual Studio’s built-in Project Template in that it defines the organizational structure and base components for an application. However, unlike the built-in templates defined by Microsoft, Enterprise Templates are created by an architect and are therefore able to reflect the specific needs of a development team.

An Enterprise Template is composed of the three following elements:

• An application skeleton (or template project), which defines the structure of the application and any standard reusable components to be included
• A policy file, which customizes the VS.NET development environment, typically by restricting the set of available commands
• Optionally, a set of custom help topics that convey additional information on development practices.

An architect who specifies corporate database access via a Web service, for example, can create an Enterprise Template that includes references to the set of standard corporate Web services, removes alternate methods of accessing databases from the VS.NET development environment, and adds new documentation to the VS.NET help system describing the corporation’s standards for data access. Any developer who created applications using that template would have all of the information needed to use the appropriate Web services, with no additional research required.

Policy Limits Options

Once a new application project is created, architects can restrict the set of available options by applying a development policy, which allows architects to remove elements (including menu or toolbox items) from the VS.NET integrated development environment (IDE) on a project-by-project basis, and to specify compiler options and other settings that cannot be changed by a developer. For example, several toolbox items in the IDE allow the developer to retrieve data from a database. An architect who has specified a Web service component for database access might remove unwanted toolbox items to ensure that developers followed the approved specification.

Without development policy, nothing in Visual Studio prevents an individual developer from ignoring the guidelines set forth by the architect and defined in the Enterprise Template. Indeed, given the large number of features available through the Visual Studio development environment, such problems are to be expected on a large development team. By allowing architects to constrain the ways in which the development environment can be used, VS.NET reduces the likelihood of such problems.

How It Works

An architect creates an Enterprise Template by creating a project structure, modifying appropriate files to make it useable as a template, and then specifying appropriate policy.

Creating a Project Structure

An architect creates an Enterprise Template by choosing "Enterprise Template Project" from the list of project types in Visual Studio, then populating the template with the appropriate set of components. The template can contain definitions for the client tier as well as middle-tier components.

At this stage, the architect is using the VS.NET development environment to add components to a project in exactly the same way she would add a component if she were building an individual application.

Preparing the Template

Unfortunately, although the process of creating a project structure is well-integrated within VS.NET, additional steps are necessary to build a functioning Enterprise Template from the project structure, and the following steps are not integrated with VS.NET:

• Entries that VS.NET uses to uniquely identify each project (specifically, a set of Globally Unique Interface IDs, or GUIDs) must be manually removed from the project files; the complexity of this process grows with the size of the project and the number of sub-projects.
• Because VS.NET looks for files with an extension of .VSDIR in order to populate the "New Project" dialog box, a new .VSDIR file must be created, usually by copying text from a sample file provided by Microsoft.
• To apply development policy to any element of the project, the architect must attach text identifiers to that element.
• Finally, the completed templates must be copied to each developer’s computer.

While some of the steps in this process can be done with VS.NET (such as editing the text of the project files), the entire process is laborious and can be error-prone.

Specifying Policy

Development policy in VS.NET is specified via a Template Description Language (TDL), which is based on XML and specifies the constraints that the architect wants VS.NET to apply to the project. TDL can be used to restrict several types of VS.NET elements, such as properties, default settings, menus, and toolboxes.

Properties. One of the most common tasks for a developer using VS.NET is setting a component’s properties. Development policy allows the architect to specify a range of acceptable values or prevent the developer from altering the value of a property at all. For example, an architect may determine the optimal value for SQL Server timeouts and prevent that value from being altered.

Default settings. Architects can specify the default settings for any new items that are added to the project. For example, an architect might specify that compiler warnings be treated as errors, thereby forcing developers to address development deficiencies earlier.

Menus and toolboxes. Items can be removed from the VS.NET toolboxes and menus, leaving the developer with only the set of options that are appropriate for a given project. Applications that rely on Web services for data access, for instance, do not need the SQL Connection item in the toolbox. Removing that option prevents the developer from inadvertently bypassing the Web service and accessing the database directly.

For an example of what the policy description looks like, see the sidebar "An Example of Visual Studio Policy".

Source Code Control Still Weak Point

VS.NET provides a set of tools for coordinating the activities of a team of developers, and while Enterprise Templates provide architects with capabilities not found in competing developer tool sets, VS.NET does little to address the key issue facing teams of developers—source code control. Source code control systems coordinate the work of teams of developers so as to avoid the unfortunate (but all too predictable) situation in which two developers simultaneously change the same portion of code, resulting in one or the other developer losing work.

A source code control system typically introduces a check-in and check-out model in which an individual developer checks out a file, makes changes, and then checks the file back in. Other developers are not able to make changes to a file while it is checked out. Source code control systems also allow developers to roll back or undo any changes that later create problems.

Visual SourceSafe, Microsoft’s source code control system for VS.NET, was acquired (along with its developer, OneTree) in 1994. Since that time, the product has languished, as Microsoft has made only minor updates (such as the ability to work with long file names). While SourceSafe supports the basic check-in and check-out features required of a source code control system, competitors such as IBM’s Visual Age products offer more complete solutions. For example, while SourceSafe (and most other systems) only roll back an entire file, Visual Age allows developers to roll back specific changes made to a function, rather than rolling back the entire file.

It is also worth noting that SourceSafe is not widely used within Microsoft. Most large development teams within Microsoft (including the Windows, Office, and Visual Studio teams) use an in-house source-code control system that, while not particularly easy to learn or use, is specifically designed for the large code bases and development teams that Microsoft uses. The result is that while other portions of VS.NET (such as the compilers and class libraries) get significant internal testing, Visual SourceSafe does not.

Resources

A walkthrough of how to create an Enterprise Template can be found at msdn.microsoft.com/library/en-us/vsent7/html/vxwlkwalkthroughcreatingnewenterprisetemplate.asp.

A second walkthrough (which builds upon the first) covers applying constraints via TDL and can be found at msdn.microsoft.com/library/en-us/vsent7/html/vxwlkwalkthroughapplyingconstraintsinenterprisetemplatepolicyfile.asp.

A complete specification for TDL is available at msdn.microsoft.com/library/en-us/vsent7/html/vxconbasictemplatedescriptionlanguagetdlconcepts.asp.