Visual Studio T4 template for SharePoint Solution (DDF)

Packaging solutions built on the SharePoint platform into WSP packages has proven to be the way to deploy your work in a structured and repeatable manner. While there are many different tools available which can support you in packaging your work, there are scenarios when they are not sufficient. As some of the tools are open source you could modify them to fit your requirements but did you know that Visual Studio can help you with creating WSP files?

The tools

SharePoint package – a WSP file – is nothing else than a .CAB file with the extension changed to .WSP. You can easily create your own WSP files using the Makecab tool: a tool which is shipped as a part of the Microsoft Cabinet Software Development Kit. All you need to do is to create a DDF file which lists all the different files that you want to include in your package. This is when things get difficult.

Imagine working on a SharePoint Web Content Management (WCM) solution. The difference between WCM solutions and other SharePoint solutions is that you will very likely include in your WSP package some branding Features. Such Feature contain very often many different files like images, Cascading Style Sheets (CSS), JavaScript (JS) and maybe some other assets like Silverlight XAP files. In order to provision all of these files you have to include every single one of them in the DDF file. If your team is doing it manually I hope you’re not the one picking the shortest straw…

Creating and maintaining a DDF file is a tedious and time consuming process. It might get particularly complex if you’re working in a team of multiple developers on one SharePoint Solution. Many SharePoint developers experienced such issues, and some of them decided to create some tools which would allow them to automate the generation of the DDF file.

Visual Studio extensions for Windows SharePoint Services (VSeWSS) WSPBuilder, and STSDev are some of the most popular tools that simplify the process of packaging solutions. They are all different and use different approaches to generate WSP files. And yet there are situations when these tools might won’t be sufficient.

When tools aren’t helpful

Using an existing tool means following the thinking pattern of its author. Depending on the tool it might be something that is considered a best practice or it might be something more exotic only a few people know about. At the end of the day it’s up to you and you development team to make an educated choice whether a particular would or would not work for you.

So why is that some of the most popular tools created to help you, wouldn’t be useful?

One of the reasons for not using any of the existing tools is developing solutions in an existing software factory. This scenario is probably most common in larger software companies that have been developing software for years. To standardize their work (across divisions/teams/platforms/etc.), such companies create often their own abstraction layers that can be applied to virtually all kind of solutions no matter the target platform. Working within a solution factory might not only mean structuring projects in a different way than supported by the tool but also using a different build procedure. In such situations the companies are more likely to find their own way of packaging solutions that integrates with the existing solution factory than using a third party tool.

Another quite common reason for not using community tools is using a different project structure. Including the SharePoint 12 system folder is probably the most common concept that you can find in SharePoint solutions but it’s not the only way of getting things done. It all depends on how experienced the development team is. It might be a common thing among experienced SharePoint developers but it wouldn’t mean anything to a .NET or ASP.NET developer. Using an existing tool in such scenario might only get things more complex and work counterproductive.

Exceptional OCD

Here at Imtech ICT Velocity we’re using Imtech SharePoint OneClickDeployment - a custom tool that allows us to provision SharePoint content and structure in a structured in repeatable way. The idea behind the tool is to give us the ability to provision not only the assets but the content and structure as well and all that without making the deployment extra complex. One of the things we’ve done to achieve that was to package the OCD configuration files inside the WSP package. During the configuration process OCD unpacks its files from the WSP package and provisions the modifications.

In order to create WSP packages that contain not only the regular assets but OCD files we had to figure out a way to create the DDF file. All of the tools we had looked at, were depending on a static predefined project structure. As most of these tools ship with the source code, we could of course extend them to fit our needs. The downside is that we would have to do that each single time a new version was released. Instead I’ve found an easier way to get things done.

“Do we really need a tool for that?” aka “A text file is all you need”

Recently I found out about Visual Studio T4 templates. T4 templates are text files with an ASP.NET-like syntax. You can use templates to automatically generate files. The mechanism is quite powerful but the best part is, that it’s available in a standard install of Visual Studio: you don’t need any extra tools of add-ins meaning every developer can use it on his machine.

To automatically generate DDF files which would meet our requirements I have created a Visual Studio T4 template. Each time after executing the template, the DDF file gets rebuilt. To really benefit of using a T4 template, you could include it in your build process to be rebuilt automatically each time you build your project.

Give the Imtech WSP DDF T4 template a try and download it from CodePlex.

Technorati Tags: SharePoint,SharePoint 2007,WSS 3.0,MOSS 2007,Visual Studio