Using the StsDev tool for MOSS Solutions

I have been maintaining and enhancing the stsdev project from codeplex as part of the HarmonieWeb Configuration Management and it is now at a state where most anyone within the company could take the product and make use of it.  Here I am working on documenting the changes/bug fixes we have done to get the product to where it is today.


Before reading this entire post you should take a look at the stsdev codeplex project (  There are three videos that will get you going on how to use stsdev, and will make the rest of this information actually make sense to you.



  1. The original version of stsdev provided no method of deploying web parts unless used as part of a feature and contained in the feature.xml or element.xml. 

  2. Now by placing the .dwp or .webpart file(s) in the RootFolders location and adding the <DwpFiles>…</DwpFiles> section to the SolutionConfig.xml file the webparts can be deployed the same as before.
  3. There are several default project types, all of which required some level of work to change the various files to have the correct feature icons, web part gallery icons, and web part gallery group.

  4. Thanks to the stsdev API two new projects (MicroLink GAC WebParts and MicroLink CAS WebParts) the proper MicroLink Logo is set for the feature icon as well as the web part’s web part gallery icon.  The webparts are also grouped into a MicroLink LLC. WebParts group by default.
  5. stsdev creates a custom targets file for use with building the application.  In this file was stored the absolute path of stsdev when the targets files was created.  Thus if two developers used stsdev but had it in different locations, then they would constantly have issues.

  6. The new stsdev installer now adds the stsdevpath as an environment variable so that it can be referenced in the target file rather than the absolute path.
  7. The wsp destination location has been changed to the bin/[configuration] location.  This supports the MSBuild when executed on TFS.

Bug Fixes

  1. stsdev originally seemed to allow a user to select the strong name key and use it for assembly signing, but this never worked.  In the end you had to use a strong name key the application created.

  2. Selection and Use of the desired strong name key is now working.
  3. stsdev provides several debugxxx configuration options, which really save a LOT of time.  However, only the DebugBuild ever contained debugging information, thus all that time saved was for not!

  4. Now All Debugxxx configurations include full debugging
  5. Also noted was that the ReleaseBuild included debugging information.  This has now been changed so that no debugging information is included.
  6. stsdev included a releasebuild configuration, however it would always fail because it was unable to find the .ddf file.  However, thanks to Athens Holloway, the correction to the target file was made to not delete the .ddf but rather delete the wsp file.
  7. The projects created by stsdev set the Generate Serialization dll to automatic, however this version now sets that to Off.  This prevents the build from failing with an sgen.exe error.

So now that you see what has been fixed in stsdev, what does it do for you?

STSDEV is a windows console application that creates VS2005 and VS2008 projects/solutions with custom build targets so you can easily build and deploy your SharePoint solution to your local development SharePoint instance.  The tool can be added to your Tools menu so that when you need to create a new SharePoint solution it is easily accessable. 

STSDEV handles the creation and updating of the manifest.xml, and makecab ddf file.  It also provides some of the other useful files, like feature.xml and element.xml as well as initial webpart files.  That means when you build using STSDEV the output of your project is a wsp, you don’t need the CAB projects any more, and the advanced layouts are formatted propertly for SharePoint.

STSDEV is currently the project creation tool picked by the Harmonie Web team and we have made the necessary enhancements to allow it to work with the TFS build process.  We would highly recommend that everyone take a look at using this with their SharePoint solutions.

I am currently working with Athens Holloway about including the capabilities he has created to allow deployment of SharePoint solutions to remote SharePoint servers.  The end goal will be that as part of your build process you will deploy, retract, upgrade, etc your solution to a remote server ALL from within Visual Studio!