Yes, believe it or not, we still use WSPBuilder for a number of our older projects.I recently came across a bit of an oddity, though, regarding the ‘Buildmode‘ parameter. Continue reading “WSPBuilder – Buildmode oddity”
With SharePoint 2007, WSPBuilder became our standard packaging tool for SharePoint solutions. It was simple, powerful, and a damn site easier than trying to write your own manifest.
Well, SharePoint 2010 and Visual Studio 2010 followed later, and Microsoft introduced much better tooling of their own. However, we’ve still got a lot of code being packaged by WSPBuilder, and we didn’t want to have to refactor all those projects just to package them for 2010.
Fortunately, Carsten Keutmann wrote a 2010 version (still in ‘BETA’, but it works fine). It offers many of the same extensions to Visual Studio as the previous version did.
However, I recently had to automate (in Team Foundation Server 2010) the build of one of our WSPBuilder based solutions, and that’s where things got more interesting… Continue reading “WSPBuilder 2010 and TFS2010”
Recently I wrote a web part using the WSPBuilder Visual Studio add-ins. I wanted to deploy it to the BIN directory and not have to elevate the trust level of my farm, so I was going to have to write a Code Access Security Policy (CAS Policy).
Others have written good descriptions of what CAS Policy is (here is a good description by Bamboo), but the short description is that it tells your application (SharePoint) to give certain additional rights to an assembly (in our case, the web part). These rights are things like being able to access the disc, the network, or even the SharePoint Object Model!
Yup, that’s right – under default Code Access Security, my assembly wouldn’t even be able to access the SharePoint APIs. Continue reading “WSPBuilder and CAS Policies”