Automation in Visual Studio 2005 for WSS v3 Feature Development

I'm anxiously awaiting Microsoft's release of Visual Studio Extensions for SharePoint Services as mentioned by Mathew Cosier here, Mart Muller here, and Wes Preston here. When released, these new extensions should make our lives as SharePoint developers a bit simpler. In the meantime, if you follow a consistent approach when laying out the structure and outputs of your WSS v3 Feature project, it becomes possible to create useful and time-saving tools for automation inside the Visual Studio 2005 IDE. In my development environment I've defined and frequently use tools to add, deploy, upgrade, retract, and delete a WSS Solution Package (wsp). My favorite of these tools is the upgrade operation, as it allows for a quick "build and test" iterative development cycle. Behind the scenes, each of these tools call the appropriate stsadm.exe operation and display the command's result in Visual Studio 2005's Output Window.

As I previously mentioned, for these external tools to be useful across all of your WSS Feature projects requires consistency in how you structure the artifacts and outputs of your project. In an earlier post, I walked you through the anatomy of a WSS v3 Feature project. Three key factors of my example Feature project's anatomy allow my external tools to function and be re-used. Please take a look at my earlier post for the specifics on how these are implemented:

1. Makecab.exe is called from the Visual Studio project's AfterBuild target to create the WSS Solution Package including the project's freshly compiled assembly.
2. The WSS Solution Package (wsp) is placed in the Package subfolder by Makecab.exe each time it is rebuilt.
3. The WSS Solution Package's name is defined by the Visual Studio 2005 $(TargetName) variable.

Let's take a look at specific implementation for each of the external tools I'm using. To define these tools, from Visual Studio 2005 go to Tools->External Tools on the menu bar.

WSP Solution Add

Command: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\STSADM.EXE

Arguments: -o addsolution -filename "$(ProjectDir)Package\$(TargetName).wsp"

WSP Solution Deploy Global

Command: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\STSADM.EXE

Arguments: -o deploysolution -local -allowgacdeployment -allcontenturls -name $(TargetName).wsp

WSP Solution Upgrade

Command: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\STSADM.EXE

Arguments: -o upgradesolution -local -allowgacdeployment -name $(TargetName).wsp -filename "$(ProjectDir)Package\$(TargetName).wsp"

WSP Solution Retract

Command: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\STSADM.EXE

Arguments: -o retractsolution -local -allcontenturls -name $(TargetName).wsp

WSP Solution Delete

Command: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\STSADM.EXE

Arguments: -o deletesolution -name $(TargetName).wsp

As a bit of review, remember that the WSS Solution Package framework involves two-stage operations for both deployment and retraction. WSP packages must first be added to the solution store and then forward deployed to the Farm. Conversely, WSP packages must be retracted from the Farm and then deleted from the solution store in order to be removed.

Keeping the WSS v3 Solution Framework's deployment mechanisms in mind, doing a WSP Solution Add command followed by WSP Solution Deploy would get your project initially deployed into the SharePoint Farm. Running WSP Solution Retract then WSP Solution Delete would remove your project from the Farm and the solution store. As I mentioned earlier, the command I use most frequently is WSP Solution Upgrade. Upgrade allows me to iteratively cycle my code changes into SharePoint and simply hit refresh in my browser to see the updates.

Having these stsadm.exe call available directly from Visual Studio 2005's IDE has saved me a lot of clicking, typing and time. I'll finish up with a few "where do I go from here" thoughts. If desired, a developer could completely automate the package upgrade process by adding stsadm.exe's upgrade operation to the AfterBuild target of the project. Taking things a step further, stsadm.exe's extensibility can be leveraged to create additional external tools such as AC's WCM Custom Commands for STSADM.EXE.

Categories: sharepoint, wss, software, development, programming, microsoft, visual-studio