• http://blogs.msdn.com/brianwilson/archive/2007/03/05/part-1-event-handlers-everything-you-need-to-know-about-microsoft-office-sharepoint-portal-server-moss-event-handlers.aspx
• http://www.davehunter.co.uk/Blog/Lists/Posts/Post.aspx?ID=69

• GlobalNavSiteMapProvider
• CombinedNavSiteMapProvider
• CurrentNavSiteMapProvider
• CurrentNavSiteMapProviderNoEncode

That is, all of these SiteMapProviders use the same base code to generate a data source, but their “output” differs slightly due to the different attributes that are applied.

Recently, we wanted to filter out the pages from showing up in our left-navigation. You can do this at the rendering stage, but since the PortalSiteMapProvder gives us an IncludePages property, we can simply create a new entry in web.config for our “custom” provider, like this:

<add name="CurrentNavNoPagesSiteMapProvider" description="CMS provider for Current navigation" type="Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider, Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" NavigationType="Current" EncodeOutput="true" IncludePages="Never" />

By default, there is also a 50 returned-items limit; we can set the DynamicChildLimit to “0″ to override this.

<add name="CurrentNavNoLimitSiteMapProvider" description="CMS provider for Current navigation" type="Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider, Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" NavigationType="Current" EncodeOutput="true" DynamicChildLimit="0" />

Of course, you can combine the different properties to come up with a combination you need. The next thing we would need to do is reference these new providers, and voila!

And if you haven’t read Chris Richard’s series of articles about MOSS Navigation and how to get better performance using the PortalSiteMapProvider, you really should…

SPSite Represents a collection of sites on a virtual server, including a top-level site and all its subsites. Each SPSite object, or site collection, is represented within an SPSiteCollection object that consists of the collection of all site collections on the virtual server.

Mmmmm… ooo-kay… what does that mean?

The SPWeb class simply says:

Represents a SharePoint Web site.

Wow. Enlightening. Looking back to my first experiences working with the SharePoint object model in WSS2/SPS2003, I must say this was one of the more confusing points for me. And it’s easy to see why it can be such a confusing/frustrating experience for developers working with the API for the first time. Now that I’ve worked with WSS3/MOSS code more closely, specifically with Publishing Sites where there are many child “sites”, I’ve come to understand the world of SPSite and SPWeb objects.

The problem lies with the difference in terms used between the SharePoint user-interface and the object model. When we are speaking to end-users, they are familiar with the term “creating SharePoint team sites”. However, everytime you create a “site” from the UI, an SPWeb object was created.

It doesn’t help that the MSDN documentation uses the following type of naming conventions in their code samples:

SPSite mySiteCollection = new SPSite("http://servername/");
SPWeb mySite = mySiteCollection.AllWebs["Site_Name"];
SPWeb myRootSite = mySiteCollection.RootWeb;

For me, it would have been much clearer if they wrote something like this instead:

SPSite mySite = new SPSite("http://servername/");
SPWeb myWeb = mySite.AllWebs["Site_Name"];
SPWeb myRootWeb = mySite.RootWeb;

While the description for SPSite may be valid, a typical SharePoint application web site only has one top-level site collection. Therefore, in this url http://servername/site1/site1a/, there are actually three SPWeb objects, and only one SPSite object.

SPSite site1 = new SPSite("http://servername/site1/");
SPSite site1a = new SPSite("http://servername/site1/site1a/");
bool sitesAreEqual = site1.Equals(site1a);  // sitesAreEqual should evaluate to true.

SPWeb web1 = site1.OpenWeb();
SPWeb web1a = site1a.OpenWeb();
SPWeb rootWeb = site1.RootWeb; // or site1a.RootWeb; would return same instance.

See the SPSite.OpenWeb() method for more examples: http://msdn2.microsoft.com/en-us/library/ms474633.aspx.

SPSite itself is not a “collection” in the sense that comes from CollectionBase, for example. In fact, both SPSite and SPWeb inherit directly from System.Object. Therefore, to use a name such as mySiteCollection is confusing/misleading.

The key thing to keep in mind is that as developers, we need to use the technically accurate terms when speaking with each other (even if MSDN doesn’t), and reserve the marketing/UI terms when speaking with people who would never see the object model. (Note: there are examples of these kinds of terminology differences all over the place in SharePoint 2007.)

I hope this clears things up a bit…if you find something that is not correct/accurate, please let me know!

Anyone who’s done some development work with SharePoint probably already knows about this article, but I wanted to place it here for reference:

Best Practices: Using Disposable Windows SharePoint Services Objects

Review the article very carefully… there are things we do often such as getting to an SPSite’s RootWeb, like this:

SPSite site = SPControl.GetContextSite(HttpContext.Current);
SPWeb rootWeb = site.RootWeb;

In this case, it’s pretty obvious (based on the article) that we need to call:

rootWeb.Dispose();

However, if you were to access a property like this:

string rootWebTitle = site.RootWeb.Title;

the article states that you should call

site.RootWeb.Dispose();

which is not obvious, in my opinion. So to keep/ensure your SharePoint site/application runs as smoothly as possible, clean up after yourself! 

EDIT (September 2008):

This is kind of old news by now, but here is another article from Andrew Woodward (which references 3 articles other than MSDN). Worthy to note that we need to properly Close() all PublishingWeb objects as well.
http://www.21apps.com/2008/02/sharepoint-ate-all-my-memory-dealing.html

Roger Lamb’s blog has some really good examples. Also make sure to read the comments.
http://blogs.msdn.com/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx

Stefan Gossner gives a pretty good in-depth look at how memory is consumed.
http://blogs.technet.com/stefan_gossner/archive/2007/11/26/dealing-with-memory-pressure-problems-in-moss-wss.aspx

Finally, a post about application pool/worker process recycling and SharePoint.
http://blogs.msdn.com/steveshe/archive/2007/12/17/overlapped-recycling-and-sharepoint-why-sharepoint-requires-it.aspx