To dispose or not dispose, that is the question...

Most SharePoint developers now know the importance of disposing SPSite and SPWeb objects.

Most of this information are not coming from the SDK but are trickling out by Microsoft employees, mainly from Roger Lamb and Stefan Goßner blogs.

Stefan's latest post is a very good and should be required reading

However, the advice and guidance keep changing and being amended.

This means developers need to make sure they are keeping up with the latest information.

For example, at one stage we were told to dispose the SPWeb object after calling SPSite.Owner. Now we should no longer do that.

This is not an ideal since it will require another review of your code.

Also, are these blogs to be viewed as official guidance from Microsoft?

For example, the newly released "Patterns and Guidance" links to Rogers blog.

We are almost two years into the product lifecycle and we are still learning best practice when it comes to writing memory efficient code.

For the next version of SharePoint it would be a lot better for this information to be provided in the SDK from day one.

Also, don't get me wrong!

I think Roger's and Stefan's contributions are fantastic.
Everyone really appreciate the work they are doing.

For the time being, make sure you subscribe to Roger's and Stefan's blogs!

Slides from SUGUK presentation

Really enjoyed presenting at the SharePoint User group in London last week!
I had a great time and I hope the audience got something out of it.

I intend to follow up with a few blog posts where I will talk about some of the topics covered in the presentation.

You can download the presentation here.

Centrally controlling "SharePoint Desinger Contributor Settings"

SharePoint Designer 2007 is a powerful tool used to design and modify SharePoint sites.

Some of you might have seen this recent post from the SharePoint Designer team. It discuss various ways of removing permissions, either at web application or site level to limit what a user can or can't do.

The post also talks about "SharePoint Designer Contributor Settings" and how they are controlled at site level.

I would like to share a way we found to centrally control the contributor settings.

Before doing that it might be useful to understand what happens when contributor settings are turned on.

1. An .htm file is saved to the _contributor_settings folder at root of the site. This file contains the settings specified by the site owner.
   
2. "vti_safeditingconfigurl" is created at the sites property bag (spweb.properties). This property contains the URL for the .htm file created in step one.

The "vti_safeditingconfigurl" property will read by SharePoint designer every time the site is opened.

Knowing that the "vti_safeditingconfigurl" contains the URL gives us an opportunity to manipulate its value!

Our solution uses two components.

1. A contributor settings .htm file (spdsettings.htm) which we store in the "_layouts" folder.
   (The file was created in SharePoint Designer and then exported).
   Storing the file in the "_layouts" folder means that all users have access to the file and that no one can modify it without access to the file system.


2. A hidden feature receiver to set the "vti_safeditingconfigurl" property to "/_layouts/spdsettings.htm" at site creation time. We achieve this by using a Feature Staple.
   (See here and here for more info regarding Feature Stapling.)

Now every time a user creates a site, the "vti_safeditingconfigurl" property will be set and point to the location of our centrally controlled file.

If a site owner tries to disable the contributor settings, they are met a message saying "Couldn't persist Contributor Settings configuration."

This is good news because it means no one can disable our centrally stored contributor settings!

So remember: "vti_safeditingconfigurl" is the key to control SharePoint Designer Contributor settings!