Why not just use the Visual Studio Extensions for SharePoint?
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:
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
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...
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...
The CMH.WebPartsWSP Post-build.bat will then run...
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.
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.