Social Enterprise

Encouraging the use of architectural standards in a .NET environment

Implementing your architectural designs in the development environment is often quite a challenge. Fortunately, .NET provides the necessary tools to make the process as painless as possible.


One of the most challenging aspects of being an architect is implementing your architectural designs in the development environment. Luckily, the .NET environment is built on a series of templates and scripts that you can modify to let developers start from a known state. You can modify the scripts and templates to configure the start-up environment in order to support standards you wish to enforce or to eliminate annoyances Microsoft has introduced into the environment. In this article, we look at the structure of these environment assets and how they may be modified.

VS template storage
When you install Visual Studio, the installer loads all the Visual Basic startup templates in the following location (templates for other languages follow a similar pattern):
C:\Program Files\Microsoft Visual Studio .NET\VB7\VBWizards.

Within this directory, you find a series of subdirectories, each containing two directories named Scripts and Templates. Each subdirectory represents a project or object type that can be created by choosing Open, New, Project or Add, New, Item from the Visual Studio development environment. The Scripts directory contains JScript that the VS Environment’s script engine executes after loading the files from the Templates directory. By modifying these Templates and Scripts directories, you can change the way the environment creates these base objects. You can also add your own templates and scripts to generate custom projects and items.

Keep your .NET skillset sharp
Receive the latest updates about this much-talked-about computing platform every Wednesday. From tapping .NET-compliant data stores to importing .NET My Services functionality, our .NET e-newsletter will keep you on the cutting edge of the distributed computing revolution. Sign-up now!

Fixing the Option Strict problem
One of the most annoying aspects of the Visual Basic development environment relates to Microsoft’s decision to allow late binding. By turning Option Strict Off by default, many type-casting errors are not caught until runtime. You can make VB work the same as other MS languages (which always do strict type-checking at design time) by modifying these templates.

Before you do this, you should first back up the entire VBWizards directory. If you make a mistake, then the templates will not load in the VS environment. You need to be able to restore the default templates if your updates cause problems.

To configure each template to default Option Strict to On rather than Off, load each .vbproj template with VB source code into an editor like Notepad and then change the XML that defines the template. For example, to do this for the Windows Application template, load the file:
Windows Application\Templates\1033\WindowsApplication.vbproj

under the VBWizards directory into Notepad and find the settings Element. You should see something like this:
<VisualStudioProject>
<VisualBasic>
<Build>
<Settings OutputType = “WinExe”>
<Config . . . .

Now, add the following lines under OutputType:
OptionStrict = “On”
OptionExplicit = “On”

Technically, you do not have to add the Option Explicit directive, because this is the default for VB; but I like to do it for consistency. Next, you must save the file and close Notepad. Now, if you load a new Windows Application project in the VS environment and examine Project Properties, you will see that Option Strict has been turned on by default.

In order for this setting to take effect for all project types, you must update each of the corresponding .vbproj templates. After making the changes on your system, you’ll need to deploy the new templates to each of your developers’ machines in order for their new projects to derive from the updated templates.

Other useful updates
If you analyze the underlying templates and scripts, you’ll see lots of opportunities to customize the environment. For example, the default Web Services template includes a hokey “Hello World” sample application that’s commented out. Rather than this code, wouldn’t it be more useful to include documentation or a sample template with attributes demonstrating your preferred transaction model or naming conventions? You can modify any of the template files to create an environment within which new projects have built-in support for some of the standards necessary to implement your architectural designs efficiently.

Editor's Picks