Geeks With Blogs
Michael Van Cleave Traveling the technical world, learning the language

On the project I just completed I was in need of the ability to quickly package a site definition, web parts, and workflows for a custom SharePoint site. I ended up using 3 different techniques in order to package the 3 different solutions. Which in the long run I wouldn't recommend, but overall I now have a much deeper aspect of the different techniques I used. I will detail the pro's and con's I found for all of them and you can make your own decision as to which one you would use to suit your development needs.

Visual Studio 2005 Extensions for WSS 3.0 v1.1

Since the project was going to be completed with VS 2005 I used the extensions to help develop the solution for the site definition part of the project. This add-on that you can download from MSDN is a must have for any SharePoint developer. The problem is that with all of the great things that it offers to the developer it also offers just as difficult to use or ambiguous functionality. Also I found the User Guide that is supposed to make using the tool easier offered very little or out of date information.


  1. Includes the Solution Generator
    1. You initially can set up a site that mimics the structure of your site or list and run this tool against the site to build all the necessary files. This is a big time saver.
  2. It has many different templates that are useful for creating a wide range of different objects in SharePoint. You have choices like Webpart, List, Site Definitions, and many more.
  3. It is an add-on to VS and provides an additional view. The WSP view helps the developer package the different project objects in to a SharePoint solution.
  4. It automatically includes any new additions to the project to the solution package
  5. The tool also gives the developer a Deploy option that will build the package, add the solution to SharePoint, and deploy the solution.


  1. As stated above in the introduction to the tool, it is the lack of a good, clear, and up to date User Guide. By far I see this as a huge problem.
  2. Lack of rich interaction in the WSP view. In order to do much of anything with the WSP view you have to either use 'F' keys or a couple of tool bar buttons that are offered.
  3. Lack of ability to package dependent assemblies in to the package.
    1. I am not sure if I was just missing something that wasn't obvious or if the User Guide didn't cover it, but I had a 2 other assemblies that I needed to be deployed with the site definition and after some time trying I failed to get them to package and deploy correctly.

Traditional MakeCAB with Packaging .bat files

The inherent manual functionality that any developer has with developing SharePoint solutions is the ability to use an XML manifest file and a MakeCAB build file to create a solution package. I won't really rehash how to do this, but if you need a good reference you can find many blogs and articles on this topic. But the technique I used was right in line with what Ted Pattison defines in his book Inside WSS 3.0. I chose this because I personally find his practice easy to understand and also easy to explain to any other developers that might come on to the project or in case of the need to transfer knowledge.


  1. The developer has a great amount of control and granularity in creating the solution.
  2. This strategy gives the developer a deep understanding of how a solution packages are created.
  3. There is a lot of good information as to how to put a project together in VS to accomplish the creation of the solution package.


  1. There is a lot of manual labor that has to be done every time you set up a project that will use this strategy.
    1. Although after the first project you will more than likely have some template files you can use to get up to speed more quickly, but nevertheless it is still a very manual process.
  2. Anytime the developer adds new files to the project that needs to be packaged then the file reference needs to be added to the manifest and MakeCAB build file.
    1. The manifest file is not too difficult to understand, but the MakeCAB file can become difficult to follow or debug if there is an error.


WSPBuilder is nothing less than a Visual Studio Add-in godsend. This is a great tool and is very easy to use. Not only that, but it comes with a single very small read me document that is very concise about how to use it. The add on for VS is very similar in concept to the Extensions mentioned above, but it does a much cleaner job allowing the developer to implement dependent assemblies and still maintain a very granular control over the solution like the traditional strategy.


  1. Easy to use, and has an up to date readme.doc that is very clear as to how to use the tool.
  2. Add-in to Visual Studio
  3. Creates WSP package and also some additional deployment .bat files
  4. Has a console side that can be used for Continuous Integration setups.
  5. Allows for granular control of the package, but also doesn't have the overhead of having to setup the base project structure and other common files as in the traditional strategy above.
  6. The tool also gives the developer to deploy dependent assemblies and files to the various folders that can be used with SharePoint development
    1. Folders like the GAC, Bin, and others are creatable in the folder structure of the WSPBuilder project template.
  7. Contains many of the same templates that come with the Extensions add-in mentioned above.


  1. To this point I haven't found any CONS to this tool. It really is the best of the 3 strategies. It is much easier to use with less manual setup.


As far as I am concerned the WSPBuilder is by far the winner in my book. It provides the necessary level of granularity and ease without all of the manual setup of the manual project files and structure. Not that I don't like the manual I just don't like performing redundant tasks. Also from what I understand there might be a CodePlex project that will build the Ted Pattison project structure for you, but I haven't worked with it so I really cannot comment much on it.

Now, I know that some of the pros and cons are probably different from what you might be experiencing, but if you have one that you would like to add to any of these or even another tool that you think should be included then I would love to hear from you.

Link References

  1. Visual Studio.NET 2005 Extensions for WSS 3.0 v1.1
  2. WSPBuilder
  3. CodePlex
  4. Inside WSS 3.0

Hope you have enjoyed this evaluation of the solution builders.


Posted on Monday, August 18, 2008 2:41 PM SharePoint , General Ramblings , .NET | Back to top

Comments on this post: SharePoint Solution Generators

# re: SharePoint Solution Generators
Requesting Gravatar...
What about STSDEV? This is becoming a great way to kick start Solution Development in Visual Studio.
Left by Jeremy Thake on Aug 20, 2008 11:55 PM

# re: SharePoint Solution Generators
Requesting Gravatar...
Thanks Jeremy, I will take a look at it to see where it compares. Have you used it? What do you think?
Left by Michael on Aug 21, 2008 8:44 AM

# re: SharePoint Solution Generators
Requesting Gravatar...
Hi Michael,
Thanks for explaning the different techniques related to these different tools. I am wondering whether it makes sens to use SharePoint Solution Generator to reverse engineer an existing MOSS site, then adjust the reversed solution to make it work with STSDev? If we compare the 3 tools: SharePoint Solution Generator, WSPBuilder and STSDev, only SharePoint Solution Generator can help you to reverse existing List or Site. If someone give you an existing MOSS site as a prototype without clearly defined development and deployment strategy, would you advice to use SharePoint Solution Generator first to reverse engineer, than use either WSPBuilder or STSDev to do further development with VS 2005 for the site?
Thank you in advance for your advice.
Left by Thanh-Nu Leroy on Oct 20, 2008 3:01 AM

# re: SharePoint Solution Generators
Requesting Gravatar...
Absolutely. I would see that as a great path for getting the site definition exported so that you can get to the meat of development faster. However you will have to be careful when you estimate this task. The reason I say that is because if you are trying to reverse engineer a publishing site in MOSS then the Solution Generator doesn't do a good job of exporting publishing sites. Usually you will run in to errors. So beware of that.

Left by Michael on Oct 20, 2008 9:25 AM

# re: SharePoint Solution Generators
Requesting Gravatar...
Thanks for your reply. Yes, I have already gone through the bugs generated by SharePoint Solution Generator :-) The reverse engineer site concept is a nice one, too bad it behaves like an unfinished product!
Left by Thanh-Nu Leroy on Oct 20, 2008 11:47 AM

# re: SharePoint Solution Generators
Requesting Gravatar...
I have a latter blog entry on the same idea but with using SharePoint Solution Generator 2008 and WSPBuilder. I was dismayed when I saw they hadn't updated the tool to handle Publishing Sites. But all is not lost! You can do a team site and then turn publishing on!
Left by David Jacobus on Nov 19, 2008 11:51 AM

# re: SharePoint Solution Generators
Requesting Gravatar...
You are absolutely right. Thanks for your response.

Left by Michael on Nov 19, 2008 11:56 AM

# re: SharePoint Solution Generators
Requesting Gravatar...
But a team site with publishing turned on does not behave the same way as a publishing site.
fx. the standard webparts is list webparts instead of content query webparts.
Left by Claus on Feb 19, 2009 4:57 AM

Your comment:
 (will show your gravatar)

Copyright © Michael Van Cleave | Powered by: