Inconvenient SharePoint Solution Generator
While working with the SharePoint Solution Generator (a utility which ships with Visual Studio 2005 extensions for Windows SharePoint Services 3.0) I have stumbled upon an interesting by-design feature which affects the way you develop Features - at least if you’re using or planning to use the SharePoint Solution Generator (SPSolGen).
SPSolGen allows you to create a List Definition based on an existing list. It is extremely useful since the CAML schema definition is almost unreadable if you work with complex lists. What SharePoint Solution Generator does is it allows you to select an existing list using a GUI and then creates for you a Visual Studio 2005 project which contains the exported List Definition wrapped up in a SharePoint Feature.
In my previous article I have described the problems I have faced while using SharePoint Solution Generator on my development environment using Visual Studio 2008. Briefly: SharePoint Solution Generator doesn’t work at all. While working on a solution for this problem I have had a look at the code of SharePoint Solution Generator to figure out the way it works.
After I have finished my solution I have started it. Exporting a list created using one of the standard List Definitions (like Documents, Custom List, etc.) worked perfectly. Then I have added the exported List Definition into my existing ContentDefinition Feature which wraps up provisioning custom Columns, Content Types and List Definitions. After creating a list based on my newly exported List Definition I have noticed that I’m not able to export it using SharePoint Solution Generator anymore. An export resulted each time in an exception: Object reference not set to an instance of an object. After some research I have found out the reason of this error.
In my previous article I have mentioned that SPSolGen modifies the Schema.xml after it has been exported. These modifications are required in order to make the List Definition work. At some point SPSolGen checks to which Feature the List Definition belongs. This information is obtained using the XmlNode.SelectSingleNode method which, I have figured out, was the source of the exception I have faced.
At the point of deployment my Feature contained the definition of custom Columns, Content Types and List Definitions in this particular order. The SelectSingleNode method, used by SharePoint Solution Generator for obtaining Feature information, retrieves the first node which complies to the given XPath parameter. In case of my Feature the Columns definition instead of the Element Manifest containing my List Definition. As the Columns definition doesn’t contain the ListTemplate element, the export method throws the exception I have mentioned before. Turning the Element Manifests around and putting the List Definitions before Columns solved the problem eventually. The Element Manifest containing the List Definition has to be the first Element Manifest defined in your Feature in order to be able to export a list based on this List Definition using SharePoint Solution Generator.
Such an approach has a major drawback: you are not able to provision multiple List Definitions from one Feature. Both methods for obtaining Feature and List Definition information use the SelectSingleNode method which retrieves the first node selected by the passed XPath query. This fact changes the approach to the custom development in SharePoint 2007 as it requires you to define a Feature for each List Definition you want to provision.
In my previous article I have mentioned that I will try to publish a custom StsAdm command allowing you to export existing lists to List Definitions in development environments using Visual Studio 2008 as soon as possible. Before the release I will try to think off a better alternative to the SelectSingleNode method which will provide the developers some more flexibility. Feel free to comment if you have any ideas or suggestions.
Technorati Tags: SharePoint 2007, SharePoint, MOSS, WSS, Best Practices, Development, VSeWSS