he brand new 3.0 version of Windows Sharepoint Services (WSS) is no lightweight release. In fact, if you’ve had a chance to look through the new WSS SDK it’s not unlikely you were a little overwhelmed with all of the new functionality in the product. And most of that new functionality comes in the form of the awkwardly acronymed VSeWSS (Visual Studio 2005 Extension for Windows Sharepoint Services 3.0).

VSeWSS is a set of extensions for WSS designed to improve the SharePoint development experience by facilitating the common tasks that all developers do. (A community preview is available now at http://www.microsoft.com/downloads/details.aspx?familyid=19f21e5e-b715-4f0c-b959-8c6dcbdc1057&displaylang=en.) Whether you’re struggling to figure out just how to create a new web part, a list definition, or a site definition—or how to deploy them—VSeWSS has a solution. It is a one-stop shop for creating SharePoint solutions.

In this article I’ll walk you through some of the most useful features of the new extensions and hopefully take the edge off your overloaded imagination.

Easy Web Parts
Let’s face it: Getting web parts up and running from scratch is a pain. By the time you add a reference to the Microsoft.SharePoint.dll file—which is buried six levels deep in the directory structure—add the appropriate using statements, derive from the right class, and override the CreateChildControls()method so that you can start to add controls to the control tree to do something useful, you’ve already spent several long minutes doing some pretty mundane tasks.

Automating this process may not seem like much to get excited about, but it can be a real timesaver when you’re creating new web parts. However, this is just the tip of the iceburg. The magic really happens when you press F5 to debug the web part. Pressing F5 starts a process that packages up the web part and deploys it as a solution to the web site. The end result is a complete deployment with just a single key press. If you’ve been testing multiple versions of a web part and have done many iterations, you’ll find that this is an absolutely indispensable time-saving feature.

Creating a new web part with the VSeWSS is as simple as selecting the web part project type from the New Project dialog as shown in Figure 1. Note that the new SharePoint folder underneath Visual C# was added by the VSeWSS.

Figure 1. The New Project dialog gets new options with VSeWSS.

Of course, there are a few limitations. There’s an absolute assumption that you’re developing locally on a server running WSS. That means that you won’t be able to do this from your workstation if you decide to write web parts from a Windows XP or Vista workstation that targets a remote WSS server. However, the best development experience will have you running a server operating system either as your primary system or at the very least running in a virtualized environment on your system; so if you’re doing things wisely, this won’t be an issue.

Now for another impressive advantage, press the F5 key again to start a debugging session. The existing solution is rolled back and a new solution is created and deployed. This ensures that you’re always running your current code while debugging your web parts.

Easy List Definitions
If you’ve ever tried to create your own list definition you know that there is a similarly mundane list of things that you must do before you can start working on the list definition itself. If they were just complex that would be bad enough, but list definitions must also conform to CAML structure, making mastery of list definitions a rare skill indeed. But things are changing: WSS introduced an XSD (XML Schema Definition) that validates the CAML automatically. VSeWSS builds on this by can create a working template of your list definition for you. Thus, today list definitions are within the reach of every SharePoint developer.

Let’s walk though the steps. After selecting your list definition’s project type you’re presented with a List Definition Settings dialog (see Figure 2). This dialog presents you with the basic range of list definitions from which you’ll select one to be the template for your new list definition. You can also create an instance of the list and an event receiver.

The event receiver option actually creates two event receiver classes. The first is an item event receiver that receives events fired based on additions, deletions, and changes. The other event receiver is a list event receiver, which is fired when fields are added or removed from the list. Figure 3shows the list schema and a part of the project file created for you automatically.

Figure 2. Pick the right list type to base your new list from.

Figure 3. Thousands of lines of code are already in your list definition for you.

In addition, getting your list set up the way you want it is easier, thanks to formerly hard-to-find properties being added automatically. If you right-click on the project, select properties and then select the bottom item, SharePoint Solution, the available properties for the project are exposed on the left (see Figure 4). You can also set or reset Guids and turn visibility of the list definition on and off.

Figure 4. The SharePoint Solution Section conveniently displays the project’s various properties.

The magic of VSeWSS is that all of the work necessary to deploy and use the new list definition is done for you when you build. Behind the scenes VSeWSS is creating a solution that deploys your event receiver (if you selected one), installs the list definition feature to SharePoint, activates the features for the list definition, and creates an instance of the list definition.

In my testing of this current version I encountered a bug that doesn’t properly register the event receivers against the list definition—if you selected that option. This bug has not yet been confirmed by Microsoft, so until further notice don’t expect your event receivers to deploy without issue.

All in all there’s a lot of work going on behind the scenes—instead of on your desktop—to create a working environment for developing and testing list definitions.

Easy Site Definitions
Something that should be a reoccurring theme by now is that VSeWSS makes the process of developing for SharePoint very easy. Site definitions are no exception to this rule. When you create a site definition you get not only the core ONET.XML and default.aspx files that you’ll need but a site provisioning handler that lets you run code on your new site definition every time it is created. This is a pretty handy thing since the CAML in the ONET.XML file can’t possibly handle everything that you may want to do when the site is started up.

As with the other project types that VSeWSS adds, using your new project is as simple as pressing F5. The site definition will be deployed and associated so that you can use it immediately. When you go to the New SharePoint Site page to create a site there will be a development tab that you can use to create a site from your new site definition.

The true power of site definitions isn’t really the ability to create a new site definition from scratch. The power exists in a standalone tool “SharePoint Solution Generator,” which promises to create a site definition from an existing site. In the next section, I’ll have a look at this new feature in detail.

Site to Definition Conversion with the SharePoint Solution Generator
Building site definitions is difficult. As a result there’s a desire to minimize the effort that goes in to them. Until now organizations would usually get a basic template down in the site definition and would then use site templates cast from those site definitions for any fine tuning. With an STSADM command you can install the site templates globally so that they can be used by any site collection. It works OK but it does require that you manage the global templates list.

The SharePoint Solution Generator opens with an unassuming dialog asking you to choose whether you’re creating a site definition or a list definition (see Figure 5). If you choose site definition you’ll be asked what site to create the definition from (see Figure 6). Once you have selected the site and clicked next, you’re asked where to store the results (see Figure 7).

Figure 5. Choosing a list definition or site definition is the first step.

Figure 6. A handy tree view allows you to select which site to convert.

Figure 7. The default location for the created definition is under My Documents.

Click Next again to get a summary checklist of what the generator plans to do (see Figure 8). Clicking the start button will convert the site into a site definition. A progress bar will inch across the screen; when it completes its journey you’ll be given the opportunity to open the exported location—or simply close the SharePoint Solution Generator by clicking Finish (see Figure 9).

Figure 8. A preflight checklist tells you what is going to happen.

Figure 9. Once completed you can go look at the Solution Generator’s handiwork.

The results of this rather unassuming operation is that you get a site definition project that VSeWSS will be able to open, allowing you to tweak the site definition and fine tune both what it includes—and what it doesn’t.

This means that you have the opportunity to skip the process of creating site templates on top of site definitions. You can now start with a customized site definition to get the overall branding, then modify the site and create a new fine-grained site definition from it.

Obviously the SharePoint Solution Generator supports the creation of list definitions as well if you need that functionality.

Starting the Show
What may once have been intimidating shouldn’t be any longer. With solid templates to get you started and the ability to generate executable code from the user interface, VSeWSS has dramatically reduced the learning curve. Creating SharePoint solutions has never been so easy.