November 2007 - Posts

• Best Practice : Using disposable objects in SharePoint

  I found this article on MSDN via Andrew's post posing the question "So is it best practice to only use C# for SharePoint development?". A good question and one that will have plenty of comment from all I imagine. For what it's worth (although not the point of this post), I'm a fan of C# because I like using (SPSite currentSite=new SPSite(http://Server)) ... The interesting thing I took from the MSDN article was that objects that are accessed via SPSite objects, like RootWeb and ParentWeb need to be explicitly disposed of when you're finished with them. I had not appreciated this. I figured that if you 'used' using on the SPSite object then that would dispose all the members etc of that object. Not so say our MS friends! This means: String str; using(SPSite oSPSite = new SPSite("http://server")) {    str = oSPSite.RootWeb.Title;    str = oSPSite.RootWeb.Url;    ... additional processing on RootWeb ... oSPSite.RootWeb.Dispose(); } And, in the interest of fairness:  Dim str as string Dim oSPSite as SPSite oSPSite=new SPSite(http://server) str = oSPSite.RootWeb.Title str = oSPSite.RootWeb.Url ... additional processing on RootWeb ... oSPSite.RootWeb.Dispose() oSPSite.Dispose() Not really that difficult, but it will make a difference to your memory usage, have positive performance benefits and keep the "Potentially excessive number of SPRequest objects (11) currently unreleased on thread" error messages out of the already huge logs! Regardless of you language of choice, this article is definitely worth a read if you are coding for SharePoint!   Posted Nov 14 2007, 09:59 AM by adrh with 5 comment(s) Filed under: SharePoint Solutions MOSS Development

• Addendum to the SharePoint Deployment Daylight Savings patch issue

  There has been much written about the issue (in particular Joel's Q&A) with Deploying Solutions on SharePoint 2007 after Daylight Savings started (and ended depending on where you are) this year and I have run into it several times. Most recently when I attempted to deploy and upgrade to a solution to a server I thought had the patch applied, but it had not. So I kicked off the upgrade, saw the job sitting in deploying (scheduled...) status, banged my head and installed the patch, rebooted, re-ran the Configuration Wizard (and lamented the time it took on setp 8!). However, after all that my job still said deploying and clicking on the Solution in Solution Management did not display the usual Cancel Deployment option.  Sooo.... stsadm time! To cancel the deployment: stsadm -o canceldeployment -id ... Of course I assumed that the ID parameter was the ID of the Solution - it's not. It's the ID of the deployment job. Incidentally, running stsadm -o enumsolutions gives you a nice list of the Solutions installed and their ID's. stsadm -o enumdeployments gives you a list of the current deployment jobs and their ID's. Plug the ID of the deployment job into the canceldeployment operation above and voila - cancelled deployment! TechNet has some documentation of the operations available via stsadm. Interestingly canceldeployment is not on the list! Mind you I much prefer to figure these things out on the fly and under pressure, don't you?     Posted Nov 09 2007, 09:11 AM by adrh with 2 comment(s) Filed under: SharePoint Solutions MOSS Development