Recently I wrote an article about automating the generation of the DDF files used to package SharePoint Solutions. In my example I used a custom Visual Studio T4 template to generate the DDF file. As a scenario I used a Web Content Management (WCM) solution, which contained a lot of assets to be provisioned to SharePoint. While working with WCM solutions generating and maintaining the DDF files is not the only challenge. As all the different assets are being provisioned using Features you also have to maintain two more files: Feature.xml and Elements.xml. Once again the T4 templates can help you get the job done.
The tools, if any?
Looking at the contents of a typical Feature.xml file you could say that it consists of two parts: the static Feature definition, which most of the times doesn’t change during the project realization and the file list which is very likely to be modified the more of your requirements will be done.
The fact that the information about the Feature is static and remains the same during the whole project is probably the reason why there are no tools to help you generate and maintain the Feature.xml file. Usually, when generating code files, the whole file is being replaced with the newly generated contents. In case of Feature.xml that would mean that you would either have to have different templates for all your Features and all the Feature-specific settings would be hard-coded in the template or you would have to have a tool which accepts parameters and generates the file based on those parameters. While both approaches seem viable they are far from ideal.
When T4 can really help you
The T4 engine is not that different from all the regular code generating tools. Using a template it allows you to generate the contents of a file. During the generation process the whole file is being replaced with the newly generated contents. So why would it be helpful for generating Feature.xml files?
First of all T4 templates are nothing more than text files. These files are being parsed by the T4 engine and the output is being generated. Because you don’t have to compile anything it is easy to make changes to the template and see the results almost as-you-type.
Another thing that makes the T4 templates useful in this scenario is the fact that you can actually include one template into another. This allows you not only to reuse the common functionality across multiple templates but also to simulate partial template generation.
T4 template for Feature.xml – the thing that does the job
To generate the contents of the Feature.xml I created a T4 template. What the template did in the first place is it looked in the directory it was stored itself, got recursively all files and subdirectories and printed out a list of all those files as specified by the XSD for SharePoint Feature Element. While it did the job the template had one flaw: it contained not only the logic for dynamically getting the list of all files belonging to the particular Feature but also the static Feature information.
The first version of the template was usable but poorly maintainable. A typical SharePoint Solution consists of multiple Features. Reusing the template across all these Features would mean copying the Feature.tt files to every Feature directory and changing the static Feature information. If a change to the files retrieval mechanism would have to be done, it would have to be done in all the Feature.tt files: not really what I was looking for.
To improve the template I extracted the file retrieval routine from the Feature.tt and replaced with a include directive. Like this the Feature.tt consists of the static Feature information and an inclusion of the files retrieval routine only. All the logic is stored separately and can be modified without changing the Feature.tt files.
Does it do the magic?
Feature.xml files can get really complex. The more assets you want to provision with a Feature the more different types of content you have to include in your Feature definition. This version of template has been made with an idea of saving you time while including all the different assets in the Feature.xml (ElementFile element only).
Depending on the type of SharePoint solutions you’re working with, you could easily extend the template to generate the ElementManifest elements as well and to exclude some files and directories from the Feature. All you have to know is the basic syntax of T4 templates. Oleg Sych did a great job of explaining the T4 engine from the very basic topics to some more advanced scenarios of how to reuse the templates across different projects and teams.