One of the things I have been working on over the past couple of weeks is setting up a standard development environment for a client. The basic goal is developing features and solution packages, so naturally I had to evaluate the latest version of Microsoft’s SharePoint development tool with full documentation included in the name - Visual Studio Extensions for Windows SharePoint Services Version 1.1 Community Technology Preview.

   

There has been a lot of improvement since 1.0 - in particular the addition of the WSP view and editing of feature manifests makes it at least potentially useful on more complex projects. Unfortunately, that way of handling the structure of solution packages is fundamentally flawed, and a nicer interface doesn’t really change that. In theory there is nothing wrong with hiding the internal structure of the 12 hive and the solution package, but in practice it just means you will have trouble using existing features as a guide as soon as you go beyond developing basic web parts. Also, it’s never entirely clear where you need to make changes or which files are source and which are generated - the internal structure may be slightly ugly, but it’s one that every SharePoint developer is familiar with and the abstracted VSeWSS model isn’t much better.

   

That said, it’s the Microsoft tool for SharePoint development, which means it can’t be dismissed that easily. So I go on to looking at what it would take to use it for more complex development, which basically means adding some new item templates to cover types of features not included in the standard package. I start by looking at building an empty feature template, something that is not included in the CTP but should be easy enough if extensibility is possible at all.

   

At first, things look promising. I copy one of the standard templates and use Reflector to see how the wizards work. There’s a public class called BaseWizard that seems to expose most of what is needed. Looks perfect, until you actually try to use it. You can extend it in any way except those that involve changing the feature or element manifests, which covers pretty much any extension that might be useful.

   

What’s missing is a way to update the solution rather than starting from scratch - there is a public interface, but the implementation (which seems overly complex) is marked as internal. You can’t even tell the project to rebuild so you know it is in a consistent state before you add something new.

   

Of course, that could just be an issue with looking at the pre-release structure, but I doubt it - all of the solution classes are duplicated in two assemblies, which is either spectacularly bad design or the SharePoint designer team going out of their way to stop me making the tool more useful.

   

Because I enjoy a challenge, I did come up with a solution that works. First, you have to get an instance of the WSP view form, because its update method is the only public method that will trigger generation of the solution files. After making sure everything from the standard templates has been generated, you can open the xml files and add anything necessary.

   

So extending VSeWSS is possible, but it’s not something I’m going to be doing. Instead I’m going with the much more stable WSPBuilder. Being a command line tool it’s not quite as easy to get started with as a set of Visual Studio templates, but that isn’t much of an issue - I’ve already created several templates, which I’m planning to release in the near future.