If you haven't tried the new Visual Studio extensions for Windows SharePoint Services v3.0 November CTP, you really owe it to yourself to take a look as soon as you can. It just might revolutionize the way you approach SharePoint solution development. Much of the initial buzz has focused on the Solution Generator, which is a very nice idea. But there is a lot more going on under the hood. In this post, we'll take a peek inside the Team Site Definition template.

The thing about site definitions that makes it kinda tough for SharePoint developers is that you have to bounce back and forth so much between XML and code. It's not so bad once you get used to it, but it's still kind of a distraction. With SharePoint version 2 we were limited in the kind of event handlers we could attach to lists, so we spent most of our time writing XML configuration files and CAML to customize our sites. Daniel Larson's excellent approach using NAnt was a step in the right direction, but things have gotten a bit more complicated. Now that we can write all kinds of event receivers, we are spending much more time in .NET land, which is where we really want to be.

This is where the VSeWSS approach makes a lot of sense. In a nutshell, it uses .NET reflection (woohoo!) to look for well-known base classes and attributes in your code, and then generates the required XML configuration files for you. It also presents a clean set of property pages in the VS environment that lets you modify the generated files. Although there are still a few issues with that part (hangs sometimes), the overall result is greatly improved productivity, especially during debugging. Let me say that part again - especially during debugging!

You'll see what I mean in a second. Let's start by creating a new site definition called "VSeWSS". As you can see in the following diagram, you get a bunch of templates in a new "SharePoint" section of the New Project dialog.

The first thing you'll notice after creating the project is the structure of the project in Visual Studio. Open the project property pages and you'll see a new section called "SharePoint Solution", with a tree of nodes. You can edit the values to customize the defaults prior to building the solution. (I've noticed that sometimes it loses the edits. This is an apparent bug in the CTP version.)

There is also a generated ONET.XML file that you can edit during the development cycle. This is where you can setup your configurations, modules, document and list templates using the standard CAML-based approach you're already used to. Of course, it's a lot easier now than it was with WSS v2.0 because the size of the ONET file is greatly reduced by the use of features.

Now comes the fun part. Simply press F5 and the VSeWSS package takes over; generating the required configuration files, copying them to the correct locations, resetting IIS and opening the web browser automatically - all in one step. As you can see from the "New SharePoint Site" page, we now have a new site definition fully deployed and ready to go.

Not only that, we're running in the debugger. Let me say that part again - we're running in the debugger.

Take a look at the generated "SiteProvisioning.cs" source file. There is a method already setup for trapping feature activation events. VSeWSS registers its own FeatureActivated event receiver that it uses to setup the web properties. I'll skip over that part for the moment. We'll explore it in detail in another post. For now, note that after it's done it calls an OnActivated method which it generates into the SiteProvisioning.cs file. Let's set a breakpoint on that method, and then go ahead and create a new site based on our site definition. While the "Operation in Progress" page is displayed, our breakpoint is hit as the feature is being activated.

Not too much to think about. Without even touching CAML, I can immediately begin writing and debugging code at the feature level. Behind the scenes, VSeWSS handled all of the grunt work, creating GUIDs, registering the assembly and generating the necessary XML files for deployment.

Here's a shot of the build log. You can see there are a lot of steps, including the generation of the solution file (WSP) and a setup batch file for installing the solution.

Now let's see what happens when we start adding features to the site. For instance, how about a new list definition? When the extensions are installed, the Add New Item dialog is populated with templates to create SharePoint items. If we select a List Definition, another little dialog pops up to specify the type of list we'd like to base our new list on, and whether to include an event receiver and create an instance of the new list.

When we press the OK button, this is what we get. First a folder is created for the new list definition. Inside, we get all the default views, plus the list definition schema (which we can edit) and code files for list and item level event receivers. We also get a new file in the properties folder containing custom attributes that are used to mark up the event receiver classes.

Of particular interest is the TargetListAttribute class which tells VSeWSS which list the event receiver is bound to. This information is used when generating the solution configuration files. Also notice that the property pages are updated to reflect the new classes in the solution. What's interesting about this is that the property pages are not static. They are dynamic.

For instance, if I were to manually create a second list definition and mark it up with the appropriate attributes, it would also appear in the property pages and be included in the solution when deployed. VSeWSS is very smart about finding the components of your solution and taking the appropriate action.

Also of interest are the element manifest properties for setting up event receivers. Directly from the property pages you can select the event you want from the list and simply set its value to True. When the configuration files are generated, the appropriate event receiver declaration is included and you're ready to go. To try it out, we'll turn on the ItemAdding event and set a breakpoint on the ItemAdding event receiver method and press F5.

VSeWSS sees that the solution has already been deployed, so it calls STSADM to retract it. Then it generates new GUIDs and deploys the new solution. Just as before, we have to create a new site to get the feature activated. Once the site is created, the new list definition appears in the site.

And since we're running in the debugger with a breakpoint set, all we need to do is create a new list item, and…

Did I mention we're running in the debugger?

With just a few clicks, we're well on the road to a custom site definition with all the trimmings. VSeWSS takes care of most of the plumbing and doesn't really get in the way of the design/build/debug development cycle. Although there are still a few kinks to iron out, the CTP release is stable enough to get started. It has already saved me many hours of hassling with CAML and XML. What's nice is that I can play with new ideas very quickly without the additional effort involved in configuring solutions and features. The other nice thing is that the debugging environment is setup already.

I'm very curious where the tool is headed, since this is only a CTP release. I'm hoping for more control over the generated files, particularly the solution file. Currently, there does not appear to be a way to specify custom sections in the solution file. For instance, if I want to add custom resources to my solution I typically would add a Resources section to the solution manifest. Since VSeWSS controls the generated solution file, I now have to wait until the end of the development cycle and add then manually add my custom sections - not good.

Another problem with the CTP is that is sometimes gets confused while reading and writing the solution files. Sometimes it keeps a lock on one or more files, generating an access denied error during the deployment step. Sometimes it hangs indefinitely while generating the WSP file, and sometimes it loses property values entered into the property pages. For example, after turning on an event receiver and debugging for awhile, the setting is sometimes lost and therefore the event receiver is not called. The first time it happens, you might miss it and scratch your head when the site does not behave correctly because you are not used to looking in the property pages when something goes wrong. Going back there, however, you'll see that the selected event receiver has reverted back to False. Now, this is the first place I look when something starts behaving badly.

Even with these glitches, the VSeWSS package is a welcome addition to my SharePoint developer toolkit. To all the hard-working folks in the VSeWSS group at Microsoft - Great work guys!

Technorati : SharePoint, Visual Studio
Del.icio.us : SharePoint, Visual Studio