WSPBuilder systems compatibility

The following table show the compatibility with different systems. The WSPBuilder is a normal console application build in c# .NET. The WSPBuilder Extensions is addon made for Visual Studio, but its still the same console application running in the background when building from Visual Studio.

System	WSPBuilder 0.9.9.0728	WSPBuilder 2010*
.NET 2.0	Yes	Yes
x32 bit	Yes	Yes
x64 bit	Yes	Yes
All versions of Windows with .NET installed	Yes	Yes
Visual Studio 2005	Yes	Yes
Visual Studio 2008	Yes	Yes
Visual Studio 2010	No	Yes
SharePoint 2007	Yes	Yes
SharePoint 2010	No	Yes

* Note: WSPBuilder 2010 may still be in beta.

WSPBuilder 2010 supports all the same systems as the previous WSPBuilder versions, so you can use it for building SharePoint 2007 (Wss 3.0) solutions without any problems.

Extract WSP packages with WSPBuilder

It is possible to extract (unpack) the contents of a WSP package into the file system with use of WSPBuilder. This function currently only supports a full extract of everything, so you have to pick what you need afterwards. The command syntax is:

WSPBuilder.exe -o extractwsp
-Filename : (Optional) Define the WSP file to extract. Default is the last created WSP file from the current directory.
-TargetPath : (Optional) Defines the target path to extract the wsp file in. Default is the current directory.
-Overwrite : (Optional) Overwrite existing files.

Example:

WSPBuilder.exe –o extractwsp –filename mypackage.wsp –overwrite true

Warning! I have not fully tested the ExtractWSP functionality in every possible scenario, so please understand.

The function is supported from WSPBuilder version 0.9.9.0728 and forward, including the WSPBuilder 2010 versions.

Project structure for SharePoint

I made a suggestion on how to create a SharePoint project structure in my "SharePoint Development" presentation at Microsoft Copenhagen back in January, but there is no documentation on it in the PowerPoint presentation.

http://www.keutmann.dk/sharepointblog/SharepointDevelopment.zip

In my experience, I find that keeping the number of WSP packages down to a minimum is the easiest thing to managed. Therefore I put all my SharePoint artifacts in one project. Some large SharePoint solutions may require more than one WSP package, but generally not many. I also separate the business logic from the SharePoint project, so it will not be GUI dependent. I use this structure as a general template whenever I create a new Visual Studio solution.

MyCompany.Framework
This project is not specific per solution, but can be used as a library across multiple solutions. This project do not contain any business or SharePoint logic, only clean .NET code. I usually create a lot of.NET Extensions in this project.

MyCompany.SharePoint.Framework
This project is for generally SharePoint related extensions and is still generic across multiple solutions. A lot of .NET SharePoint Extensions is added to this project.

MyCompany.BusinessModel (or ObjectModel)
This project will contain all my business logic and data objects. The project will not contain any UI logic.

MyCompany.MyProjectName (SharePoint Project)
This is the SharePoint artifact project from where I will build my WSP package by use of WSPBuilder. All the SharePoint webparts, features and so on will be created here. It is usually set to deploy to Global Assembly Cache. However if company policy requires the code to be deploy with Code Access Security (CAS), I will create an additional SharePoint project, so I have one project for the GAC and one for the WebApplications bin folder.

MyCompany.Test
The project for Units tests.

I do not say that this is the best structure, but I find it as a good template to start from, specially that I can reuse the Framework projects from solution to solution.

Podcast on WSPBuilder

Hilton Giesenow did this podcast on WSPBuilder with me.


Check it out.

http://www.themossshow.com/2010/04/carsten-keutmann-tells-us-about-wspbuilder/