Build WSP’s at the start of the project and just get it over with!

I was doing my daily SharePoint blog reading and ran across a blog posting by Rob Bogue where gets into how he was brought into a client site to look at some custom SharePoint code that they were having a problem with.  Naturally the code wasn’t deployed in the recommended way, nor did it apparently have a visual studio project so he was basically going from ground zero to determine the problem.

Here is my take/personal experience with a similar situation(s) and hopefully that will explain the title of this blog posting and drill it into your head.

At a previous client, I was part of a development team working on a high-profile SharePoint internet facing site.  A lot of custom coding was done to achieve various features that were required.  I brought in late to the project and was therefore not there at the beginning to stress the importance of WSP’s.  What we had was a large visual studio project with X number of class libraries that contained our custom code.  Each “feature” was its own class library that would then be packaged into its own DLL.  As you can guess, when it came time to deploy, the “build master” would then take all those DLL’s, add then to the GAC of EVERY SINGLE WEF, manually do the web.config modifications for safe controls, etc. etc.  What we had then was a few hour “deployment” process where mistakes were quite common and multiple hours of work lost. 

How would you solve this above case?  Use features/solutions obviously!  Each custom piece of code could have been written and included in the master feature, along with the web.config modifications, allowing for a single package to be deployed to 1 SharePoint server and let SharePoint use its built in features to distribute that to each server in the farm.  All in all it would have taken a few hours of work at the beginning to build the WSP project into the visual studio project work out the deployment kinks, but after that the deployment should have taken minutes, not hours every time like it did.

Onto the next example, yet again, another client project where we had multiple developers doing their own thing.  Basically it was a set of webparts with some css/xsl and images that needed to be deployed.  Luckily we weren’t at the production deployment stage, but in development we were manually doing things.  Now, I’ll admit, I didn’t follow my own rules exactly here and certainly contributed to the early struggles.  Basically we would move the update files to the _layouts folders, deploy manually to the GAC, etc.  The plan all along was to just get things going ASAP and then when it came close to our first deployment, we would create the proper WSP project/solution and do deployment the right way.  The result was that prior to our first deployment, after all this code had been written, we ended up spending about 2+ days working on just getting the stupid WSP built correctly and deploying correctly.  This EASILY could have been solved if we had just started with a WSP in the first place.

Now I won’t sit here and tell you WSP’s are the greatest thing since sliced bread and that they are SOOO easy to build/use…cause I won’t and frankly I feel they are a pain, BUT when it comes to deployment on multiple environments, I feel that the pain is worth it and they work pretty well.  Here is my current list of recommendations:

Start out from day 1 with a WSP project and then continue to use that.  You have a few choices here to help you with that.

• STSDev (I personally use/prefer this one)
• WSPBuilder
• Visual Studio Extensions for WSS

I personally use/like STSDev because it basically creates a visual studio class library for me, all the xml files, as well as having build targets built for me that handle the manifest.xml files, DDF, etc. and when I do a rebuild, I get a .wsp file everytime.  I like this because all I need is basic visual studio, and not some extra project templates that not every developer has.  I can package up my solution, send it to someone, and they can open it and work from it right away.  BUT, I do have a few things that I do that I feel help me make my development life easier.

Create 3 bat files in my project that I will use to ease deployment

• deploy_solution.bat (deploys the solution using stsadm commands)
• retract_solution.bat (retracts the solution from the farm using stsadm commands)
• reinstall_dll_gac.bat (reinstalls my code DLL(s) to the GAC and does an IISRESET)

deploy_solution.bat

CLS

"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN"\stsadm -o addsolution -filename MyCustomCode.wsp

"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN"\stsadm -o deploysolution -name MyCustomCode.wsp -immediate -allowGacDeployment -url http://{SITE TO DEPLOY TO} -force

"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN"\stsadm -o execadmsvcjobs

IISRESET 

PAUSE

retract_solution.bat

CLS

"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN"\stsadm -o retractsolution -name MyCustomCode.wsp -immediate -allcontenturls

"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN"\stsadm -o execadmsvcjobs

"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN"\stsadm -o deletesolution -name MyCustomCode.wsp

IISRESET

PAUSE

reinstall_dll_gac.bat

CLS

GACUTIL.exe /u MyCustomCode

GACUTIL.exe /i C:\PROJECTS\MyCustomCode\bin\Debug\MyCustomCode.dll

GACUTIL.exe /l MyCustomCode

iisreset

PAUSE

Now, once I have my visual studio project (created using STSDEV), I can then use my bat files to easily deploy/retract my WSP from my site (you could also if you want, wrap both these together so it retracts first, then deploys).  This works great when I want to test soup to nuts to make sure my WSP, features, xml files, _layouts, etc. are all going to the right place and there are no errors in my XML files.  BUT, what really comes in handy for my is the reinstlal_dll_gac.bat file.  What this does is reinstalls my DLL into the GAC and does an IISRESET (yes, simple enough).  The benefit here though is once I have my basic of my WSP build, feature.xml, manifest.xml. etc. and I know all those files are kosher, there is NO need to retract/deploy that EVERYTIME i want to test something, therefore only redeploying the code in the GAC is necessary.  I can then change my code, reinstall the dll, load my site, which already has my code on it, and see how the new version functions.

What should you as the reader take away from all of this? 

• Start with a WSP project from day 1 and work out the kinks at the beginning and save yourself the trouble later
• Use some simple batch scripting to make deployment, as well as functional testing, easier on yourself