Different techniques for storing application settings in your SharePoint solutions

When building custom SharePoint solutions, you often need to store and retrieve application settings such as connection strings, default values, cache expiry settings, etc. In this post, I will go through a few different options that are available and some considerations you need to make before deciding which way to go.

Application Foundations Configuration Manager
The Application Foundations for SharePoint 2010 includes several useful components such as a service locator, logging utility and application settings manager. The application settings manager provides an API to store and retrieve settings on several different levels – farm, web application, site collection and site. The SharePoint property bag at each level is used to store the values and the unique prefix PnP.Config.Key is used to avoid conflicts with other values in the property bag. The only drawback with this solution is that there is no out of the box GUI for setting and updating the values, so you need to write custom code or use the property bag editor available on CodePlex.

Configuration files stored in the 14 folder
Another option is to store your configuration values in an XML file and deploy it to a subfolder in 14/CONFIG. You can then write a simple configuration settings reader class that reads and caches the values stored in the file. The best thing with this approach is that it’s really easy to deploy your settings to different environments by creating separate configuration WSP packages  that includes the configuration settings files. However, if you need to change a value you would need to update and redeploy the configuration package. Therefore, this technique should only be used for global settings that are fairly static, and doesn’t need to be changed through the UI once the solution has been deployed.

SharePoint list
Another popular option is to use a SharePoint list to store configuration values. You can create a list on the site collection root site called Configuration Settings or similar, and store your values there. There is a handy solution on Codeplex called SharePoint config store that provides a nice API for retrieving the values and it also takes care of caching. Since you’re using a SharePoint list, you can use the out of the box SharePoint GUI to set and update the values. You can also enable versioning on the list to keep track of the configuration changes. The only drawback with this solution is that your settings will be stored on the site collection or site level. For global settings that needs to be available across site collections you would need to use one of the two previous techniques.

Web.config
Web.config should not be used for storing configuration settings in SharePoint solutions, unless there is no other option available. Unlike a classic ASP.NET application, you are not in charge of the web.config file – SharePoint is. And the only supported option for storing settings in web.config is to use SPWebConfigModification class to register the additions to web.config.

As you can see, each approach has different pros and cons and you should choose the appropriate technique depending on the scope of the setting, and if it needs to be updated  through the UI after the solution has been deployed.

No matter what option you choose, I would recommend that you create a common static configuration settings class with strongly typed property getters to access the settings. That way, you are free to use a combination of the different techniques and, if necessary, to change the underlying storage mechanism for your settings without impacting your code.

December CU for SharePoint 2010 released

Just before new year, the December CU for SharePoint 2010 was release by Microsoft. There seems to be quite a few fixes in this update.

One issue that is resolved is that browser file handling was automatically set to strict on all sites created on a custom site template, not matter what setting the web application had. The only workaround was to correct this with a WebAdded event receiver – not too pretty solution.

Our customer stores e-mail messages in SharePoint sites based on custom site templates and need to open them directly in Outlook, which requires Browser File Handling to be set to Permisive, so we’re really happy that the issue got resolved.

The list of fixes included in the December CU can be found here: 
http://support.microsoft.com/kb/2459108/

The links to the downloads can be found here: http://blogs.msdn.com/b/joerg_sinemus/archive/2010/12/31/sharepoint-2010-and-december-cu.aspx

LINQ to SharePoint is not a substitute for a repository

LINQ to SharePoint is a nice new feature of SharePoint 2010, which offer both strongly typed access to SharePoint list data, as well as translation between LINQ and CAML queries. Even though this makes data access against lists a lot easier than before, there are a few things to keep in mind before deciding to use this in your solution.

First of all, LINQ to SharePoint is NOT a substitute for a repository. The SPMetal objects that are returned from the LINQ queries are basically just strongly typed representations of the list item objects. If you need change the structure of your list, you will have to update the SPMetal classes which will cause problems of you have a lot of dependencies to these classes in your code. Using LINQ to SharePoint directly from your UI components can lead to just as unmaintainable solutions as those built on LINQ to SQL.

A lot better option (see the image on the right side) is to create your own domain classes, create a mapping between your domain class and SPMetal class and encapsulate this together with the data access code in a repository. If anything changes in the list item structure, you will only need to update the mapper and SPMetal classes, nothing else.

Also, be aware that using LINQ to SharePoint may cause a performance overhead. We have done some simple performance measurement where we compare data access through LINQ with ‘classic’ style SPQuery. SPQuery actually performs a lot better. Two possible reasons are overhead in query translation from LINQ to CAML and the mapping between SPListItem and SPMetal object. Since the overhead is just as big when executing queries that return zero items, the query parsing and translation is the most likely cause of the performance penalty.

Of course, you can also still build your repository in the same manner as SharePoint Guidance for SharePoint 2007, with your own List Item mappers and CAML queries embedded in the repository.

There are a few options here, which is probably the best argument for building a repository that returns instances of your own domain classes rather than the SPMetal generated classes. If you do that, you are free to change the internal implementation and storage model without impacting the rest of your solution.

How to include the SharePoint version in a Word document

I’m currently working with our client’s legal department to build a case and document management solution based on SharePoint 2010.

Most of our requirements will be solved with plain OOB functionality. However, we were quite surprised to figure out that there is no easy way to add the SharePoint version number to our Word documents. When printing a document, it would be very helpful to have the version number printed on the footer, to know which version it is.

There are two workarounds for this, that I know about:

Solution 1: Use label information management policy

Add a label information management policy on the library as described in this thread. Unfortunatley, there are a few issues with this solution.

First of all it requires SharePoint Server, since information management policies are not included in SharePoint Foundation.

Secondly, it requires quite a few manual steps that most end users won’t feel to comfortable with.

Also, it seems that adding an information management policy breaks the ‘Save as site template’ functionality. We’re waiting for Microsoft support to clarify if this is a bug or expected behavior.

Solution 2: Create an event receiver

The second options is to create an event receiver that copies the version number to an additional SharePoint text column. The additional column is then available to add as a quick part in Word.

This solution doesn’t require a server license, but it does require some custom code.

Fortunately, there is a handy CodePlex solution for this. The best thing with the SharePoint 2010 version is that it’s available as a sandboxed solution. So it’s really easy to install and get up and running.

This is probably the best solution until Microsoft fixes this limitation.

Finally, I would say that this is more of a Word issue than a SharePoint issue. The information about the SharePoint version number is indeed available in Word, so there is no reason why it can’t be available as a quick part.