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.
Includes the Solution Generator
- 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.
- 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.
- 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.
- It automatically includes any new additions to the project to the solution package
- The tool also gives the developer a Deploy option that will build the package, add the solution to SharePoint, and deploy the solution.
- 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.
- 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.
Lack of ability to package dependent assemblies in to the package.
- 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.
- The developer has a great amount of control and granularity in creating the solution.
- This strategy gives the developer a deep understanding of how a solution packages are created.
- 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.
There is a lot of manual labor that has to be done every time you set up a project that will use this strategy.
- 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.
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.
- 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.
- Easy to use, and has an up to date readme.doc that is very clear as to how to use the tool.
- Add-in to Visual Studio
- Creates WSP package and also some additional deployment .bat files
- Has a console side that can be used for Continuous Integration setups.
- 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.
The tool also gives the developer to deploy dependent assemblies and files to the various folders that can be used with SharePoint development
- Folders like the GAC, Bin, and others are creatable in the folder structure of the WSPBuilder project template.
- Contains many of the same templates that come with the Extensions add-in mentioned above.
- 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.
- Visual Studio.NET 2005 Extensions for WSS 3.0 v1.1
- Inside WSS 3.0
Hope you have enjoyed this evaluation of the solution builders.