A couple of weeks ago I wrote about how my team uses a 100% Virtual development environment, the first half a SharePoint developer’s “green field” as I described it. Another major factor in creating a happy and efficient development team is putting the effort into designing good build processes. There are many variations on a theme when it comes to building SharePoint 2007 projects but I thought I would write down an overview of how we do it so as to “add to the mix”!
Why not just use the Visual Studio Extensions for SharePoint?
We looked at using these around Feb 2007 when they were still in Community Release and had a bad experience. They were very buggy (ok fair enough at the time) but most importantly we had little control over the SharePoint Solution Files (WSPs) being generated. We could neither structure the Feature directories the way that we wanted nor name the Features the way we wanted. The build was very much “all or nothing” i.e. a full build was performed each time, along with deployment to the server. In addition, the build process was very hard to debug when something went wrong. There’s a relevant
discussion thread on SUGUK talking about these kinds of issues.
So with the need for a high degree of control over our WSP files and the desire to create an efficient build we set about designing our own...
Pretty quickly we decided that it would be easier to manage and probably most logical to functionally separate our projects into:
- WebParts – WebPart code and resource files
- SiteTemplate – Everything CAML based
- Components – 3rd party assemblies and resource files.
- Webservices – Webservice asmx and supporting assemblies.
Each of these projects would result in the generation of a corresponding WSP file ready to deploy to the development server. In this article I will explain the build process for the SiteTemplate and WebParts project because they demonstrate two slightly different techniques which can then be reused elsewhere.
Site Template Build
Fig. (1)
When laying out SharePoint Features I find it most logical to replicate how the Feature will eventually appear when it is deployed on to the Front End Webserver in the “12 Hive”. Fig.(1) shows an example list, Aeroplanes, which has the usual xml files you’d expect for a List Feature.
On a successful build of the project the Post-build.bat file is called from the Post-build events (under Project Properties). The reason there is a separate file is because I hate the nasty Post-build event editing window in Visual Studio! It’s just horrid. Seeing as the Post-build events need to be edited quite a bit, it’s much easier to have the file right there in your Project so you can just double click to get editing.
The Post-build.bat scripts the whole build process and in Fig.(1) I have documented pseudo code for each of the steps it goes through. I’ll detail the steps a bit more...
- First up MakeCab.exe is used to generate a WSP file. A WSP is just a CAB file with a WSP extension. The MakeCabDirectives.ddf file is passed to the MakeCab.exe to define the WSP payload and so therefore lists the Feature xml files as well as the all important Manifest.xml.
- If the WSP generation is successful then we move on, if it’s not we’ll see some error messages in the Visual Studio Output window.
- The next steps remove any previously deployed versions of the WSP. Of course first time round these steps will fail because there will not be anything to remove.
- Then we begin the deployment steps. First we deploy the WSP to the SharePoint Solution Store using STSADM. We then have the choice of how we deploy the WSP, in development I always deploy globally where possible. The final step of deployment is to activate Features on any specific development sites.
- Inserting entries into web.config could be a requirement for many different SharePoint projects. However, we put all the modifications into the SiteTemplate project because it felt like the most sensible place to keep them (they have to go somewhere). We actually keep these modifications in an XML file (not shown in the diagram) and then apply them using the SharePoint Object Model as shown.
- Finally we perform an iisreset in case any of the CAML changes require it.
WebParts Build
Fig.(2)
There are actually two projects which make up CMH.WebPart development, CMH.WebParts and CMH.WebPartsWSP. The former contains all of the WebPart code and resource files, the latter contains the files for packaging as a WSP. We’ll look at CMH.WebpartsWSP first...
- CMH.WebpartsWSP is dependent upon CMH.WebParts, so first of all the build will compile the assembly CMH.WebParts.dll.
The CMH.WebPartsWSP Post-build.bat will then run...
- Again we use MakeCab.exe to generate a WSP, this time it contains the WebPart assemblies and resource files.
- We then retract and delete any existing solutions using STSADM.
- Next we add the WSP to the solution store using STSADM and then deploy the solution to a known application, also using STSADM.
- Finally, for good measure, we perform an iisreset.
The building of CMH.WebPartsWSP represents a “full” build, replacing all files associated with the WebParts. It’s worth noting that the Manifest.xml contains instructions for SharePoint to update its Safe Control list and Code Access Security to facilitate the running of the WebPart. So the WSP deployment really does contain everything the WebPart will need.
The only downside to a full WSP build and deploy is that it can take quite a long time. This is why we have the separate CMH.WebParts project. Once a full WSP build has been done we can then just replace the CMH.WebParts.dll in the SharePoint bin in order to make changes to the code. WebPart development mostly involves a code-change-then-test cycle, so for the majority of rebuilds all we need to update is the assembly. So, in the CMH.WebParts Post-build.bat we copy the assembly from the output target to the SharePoint bin. To test the changes all we need to do is refresh the WebPart page.
Fig.(2) also shows a QuickDeploy.bat script. This is not called as part of the build process but instead a developer can optionally run it in order to copy resource files directly to the 12 Hive (or resources directory). It’s a quick way to get resource changes into a SharePoint site for testing e.g. changes to Javascript files without having to go through a full build. There is one downside, when you subsequently try to retract the solution SharePoint may not be able to retract these files because it can see they have been modified.
One other useful thing we do in CMH.WebParts Post-build.bat is use sn.exe to output the Public Key Token for the signed CMH.WebParts.dll. This is useful because the Public Key Token is needed when writing the Manifest.xml file as well as .webpart files for each WebPart.
There you go! Some SharePoint build processes. Whilst not totally original I think they contain some nice ideas and have certainly proven to work well during the past 6 months of our project.
Just recently I was referred to:
When I have time I would like to incorporate these scripts to take the manual work out of writing .DDF files. You may want to check them out.