Wictor Wilen

If you’ve been in the SharePoint business for a while (at least a couple of days) you should be aware of the SharePoint objects that needs to be properly disposed; SPSite and SPWeb in particular. Objects that need disposal inherits from the IDisposable interface and requires that you call the Dispose() method when you’re done with the object - this is to ensure that the object frees up resources that the .NET managed garbage collector cannot free up automatically. This includes objects such as non-managed SQL connections, resource handles, file handles etc. Disposing objects is nothing unique for SharePoint - all (real) .NET developers know how to dispose of a SQL connection. You can read more about the best practices around disposing SharePoint objects in the MSDN Disposing Objects article. Not doing this properly will eventually lead to application crashes, high memory usage and/or bad performance.

The 65th SharePoint Pod Show is out featuring…tada…me :-) The SharePoint Pod Show is THE podcast about SharePoint and is done by Rob Foster, Nick Swan and Brett Lonsdale and has featured a lot of great SharePointers from all around the world throughout the years. If you haven’t already listened to the podcasts, then you got 65 episodes to catch up on! There are some epic ones, such as my favorite one #50 - which is about performance tuning. And make sure that you subscribe - you don’t want to miss their SPC11 Road-trip…

Besides SharePoint my very dear topics is performance optimizations and new technologies, so here’s a post mixing all these together. Background Caching is one way to improve the performance of any application, there are several ways to do it in-memory, disk etc etc. SharePoint 2010 has a set of caching capabilities, most of them are in-memory caches and some involve disk or even SQL based. One problem with (especially) in-memory caching is that if you have a farm different servers may display different results, which is due to the fact that the different servers cached information at different times. Another problem with in-memory caching is that it’s per process, that is that you have different caches for different web applications and application pools.

This is a short story about how you can get and resolve stale Managed Metadata Service (MMS) databases in SharePoint 2010. I’ve been working with Managed Metadata quite much and done some backup/restore juggling from production to test and to dev environments. Which by the way works really smooth. I’ve also recreated the MMS databases a couple of times. After applying Service Pack and the re-released June 2011 CU I went into Central Administration to take a look at the databases and their upgrade status. This is what I found: four MMS databases, of which two didn’t upgrade, and I only have two MMS service applications in this particular environment.

Here goes another post using the WebPartAdderExtension Element. I previously wrote an introduction to custom Web Part Gallery sources and a second one on how to enhance the end-user experience when adding new Web Parts. Now I’m going to show you another trick that this technique can be used for. Introduction Deploying Web Parts are normally done by using the Module element in the Elements manifest and using that element uploading/deploying Web Part Controls Description files (.webpart or .dwp files) into the Web Part catalog. These Element manifests for Web Parts must be scoped to the Site Collection level, since it is there where the Web Part catalog lives (~/site/_catalogs/wp). So if you want do deploy a solution containing a set of Web Parts you need to activate that Feature on each and every Site Collection. You can do it in a number of ways such as Feature Stapling, code, scripting etc. Could be quite tedious work if you have a large farm with many site collections and web applications. Also when retracting solutions with Features that uses Modules we manually have to clean up the files provisioned.

This is a follow-up post on yesterdays introduction to the WebPartAdder (which lately has been one of my favorite features of SharePoint 2010). In that post I mentioned that you could invoke a JavaScript function when a Web Part is added using a custom Web Part Gallery source. The Silverlight Web Part If you have been working with SharePoint as an end-user you’ve probably seen the nice modal dialog that pops up when you’re adding a Silverlight Web Part to a page, see the image to the right. It allows you to very easily configure the Web Part with the appropriate XAP file without editing the Web Part properties. If more Web Parts were like this it would be a whole lot easier working with Web Parts.

Writing this post has been on my agenda for some time, initially I intended to put it into my SharePoint 2010 Web Parts in Action book, but there was not enough time, you know how it is! This is an excellent new feature to SharePoint 2010 which allows you to dynamically populate the Web Part Gallery with Categories and Web Parts. So here we go. Introduction to the Web Part Adder and the Web Part Gallery Think of the List and Libraries category in the Web Part Gallery - it is dynamically populated with the lists and libraries available in the current web. This is all done using the WebPartAdder class which loads all the Web Parts available in the gallery from a number of different sources, see figure below. These source include the List and Libraries category, the local Web Part catalog, files in the wpcatalog, closed and uploaded Web Parts etc.

I guess by now we all seen or read about the new SharePoint 2010 guidance on scaling limits announced by the product group today. To sum it up it this is the new guidance on content database sizing: up to 200GB - still the recommendation 200GB to 4TB - yes, it’s been done and can be done (with the help of a skilled professional architect :-) 4TB or more - only for near read-only “record centers” with very sparse writing This looks good right, and it can be in some cases. But now on to the fine prints, which actually are written in the updated Software Boundaries and Limits article. If you read the announcement and the boundaries article you see that to be supported you need to follow a number of hard rules (such as IOPS per GB) and you must have governance rules (such as backup and restore plans) in place. Ok, if I got the IOPS needed, the best disaster recovery plans ever made and a skilled professional - should I go for the 4TB limit then? I think not, unless you really need the scale and have the hardware requirements.

About a year has passed since SharePoint 2010 RTM:ed and now the first Service Pack is released, Service Pack 1. A Service Pack is always a big deal for SharePoint. Service Packs contains all the previous cumulative updates and in most cases some new features. SP1 for SharePoint 2010 is all that. Before diving into some of the new stuff I want to raise a finger of warning. Plan and test your SP1 upgrade thoroughly! Even though Service Packs are tested more than CU’s they are not tested in your environment and with your customizations. Read more on this topic.