Why we should use Visual Studio item templates more often

Recently I have started creating item templates for visual studio. The first was for RfidEventHandler and there are more on the way. In this post I want to present why I think developers and architects should consider the use of item templates more often.

I use quite a few project templates, most of which I found on the web. Item templates, on the other hand, are not so common and so far, I haven't encountered any I can use. I think this feature is under used. It is overshadowed by its bigger and more popular brother: the project template and for really no reason. After getting acquainted with item templates, I can say that more than once I realized the project templates I find would have served me much better if they were implemented as item templates.

My main use for VS templates is when I need to write components. I work a lot with BizTalk and there are quite a few extension components you can write for it. They need to implement various interfaces and it is convenient to get a class with the stub code for all the function already generated for you. When I use a project template to create a component I get a separate project for each component. I usually prefer to put all my components in the same DLL. Many of the components are a single file and there is no reason to have a few projects with one file each.

Item templates solve my problem. I create an empty project with a properly general name like RfidEventHandlers and then start adding components to it using the component template. Except creating the project, an item template works the same way as a project template would:

• It can add to the project more than one file if the component needs this.
• The template can specify which references to other projects\DLLs the component needs. The references will be added if they are not already in the project.
• It does text replacements the same way as the project template etc.

One thing I always find problematic in project templates is that the project name and the namespace given to the classes are never what I need them to be. Project names should represent the content of the project. I prefer to give the project a short name. The namespace, on the other hand, should embody the project name but also represent its place in the overall hierarchy of code. For example MyCompany.MySystem.DataObjects). By default the namespace is created the same as the project name so I always need to set it manually in the project properties after it is created. The project name and namespace created by a template are either a fixed string or based on the given project name. In case of a project for a component this for sure will not be the name I wanted. It is easier to create the project with the name I want and set its default namespace before I start adding classes to it then to change this in a project that was created by the template. In item templates I just specify that the generated classes will get the default namespace of the project and when I add then I know they will get the namespace I wanted.

Don't get me wrong, project templates are a good thing and should be used. They are the right choice if your project needs artifacts which are relevant to the entire project. Things like configuration, setups and tests. I recommend, as I mentioned before, to create a combination of a project template for the sets up a project for components of a specific type and an item template to add components of that type.

Creating item templates is very easy and I really recommend that you to consider creating some also for your own classes. For example I found it helps to enforce the use of an infrastructure layer. My generated classes include code that initializes the infrastructure classes and contains code samples with explanations of how it should be used (in comments). In some cases the generated class will come with utility functions like a log function that add internally the class name to each log line.

Another use is to help maintain design patterns. Many of the patterns require a set of classes that will inherit from a common interface. New classes might be added by developers, sometime even a long time after the design was done and by developers that knows nothing about the architecture. To write such a class, a developer needs to look into the documentation to find which interfaces the component should inherit from and find what each of the functions in it should do. Item templates enable a developer who knows nothing about how to create the class, to do so in a few clicks. All that is needed is to know the class type. The template will generate the class for the developer with the right inheritance and stubs for the functions with default implementations. Most importantly- there will be explanations inside the code about what each function should do. This is my favorite way of learning- I think a sample with explanations in the code is the best kind of documentation.

When I first started to learn how to create an item template for Visual Studio I found this blog post by Jason Kemp very helpfully and obviously had a look at the MSDN for all the small details.

Next thing I did was to look for samples. First I searched my computer and what I found was where VS keeps the templates for the standard items that comes with the installation (class, config, etc). This is the best resource since I can pick the item most similar to the one I want to create and look how it is implemented. These templates are placed for VS2008 in the folder: 'C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplates'. If you use VS2005, the VS folder name is 'Microsoft Visual Studio 8'. You can find the unzipped versions of the templates in 'C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplatesCache'.

I'll be happy for more thoughts and comments on the subject if you have any.