How to Save Configuration Data in SharePoint Development

Written by Denis Stadler on . Posted in Custom Development

When we develop custom application over the SharePoint platform, often we need to store different configuration parameters as: connection strings, e-mail addresses, URLs or different data parameters.

In SharePoint we have the following possibilities to store the configuration data (I will enumerate them based on my preference):

SharePoint Property Bag

This can be used for all the custom SharePoint solutions (Farm, Web Application, Site Collection, Web). The only disadvantage that I found is the fact that you have to build an application page or a web part to manage this items, because there is no interface provided by default.

What I wanted to share in this article were the get/set (load/save) methods that I use to access the Property Bag in my custom solutions. Usually I create a public static class called Helpers, where I store all the common methods needed in a solution. To load and save the Property Bag data I created a LoadProperty and a SaveProperty method with two overloads each.

In case we call this method from a FeatureActivated event, we need the second overload. In this case the object SPContext.Current.Web does not exist. Anyway you can find below the code that I used:

#region Load Configuration Property
public static string LoadProperty(string strKeyName)
{
string strResult = string.Empty;

SPWeb webCurrent = SPContext.Current.Web;

if (webCurrent.Properties.ContainsKey(strKeyName))
{
strResult = webCurrent.Properties[strKeyName].ToString();
}
return strResult;
}

public static string LoadProperty(SPWeb webCurrent, 
string strKeyName)
{
string strResult = string.Empty;

if (webCurrent.Properties.ContainsKey(strKeyName))
{
strResult = webCurrent.Properties[strKeyName].ToString();
}
return strResult;
}
#endregion
enterprise-wiki-publishing-site

Step by Step: How to Implement an Enterprise Wiki

Written by Denis Stadler on . Posted in Collaboration

Post Summary

The main business reason which made me to start the discussion about the necessity of having an Enterprise Wiki was to encourage many-to-many communication between the team’s members. But, there were others like:

  • The necessity of having a central repository tool which hosts, in my case, technical knowledge and information accumulated during the IT projects;
  • The necessity of categorizing  the information (both as Taxonomy and “Folksonomy”) in order to access it faster;
  • Search engine.

Having said that, the natural choice was to implement an Enterprise Wiki in SharePoint 2010. The other advantages gained by choosing it are: Versioning, Approval (at the end Enterprise Wiki is a publishing site, but for sharing technical resources I don’t think it’s necessary).

Before strating, I would suggest consulting the following TechNet articles:

Prerequisites

In order to deploy an Enterprise Wiki we need the following:

  • A site collection created based on one of the publishing site templates or another site collection where the SharePoint Server Publishing Infrastructure feature is activated at the site collection level;
  • Managed Metadata Service and Search Services (if we want to search within the Wiki :) ) shared service applications up and running.

Implementation

Basically what I have to do is to deploy a SharePoint 2010 built-in feature. I have a publishing site collection – Intranet where I will add an Enterprise Wiki as a child site which will host my content.

Step by Step: How to Implement a Three-Tier SharePoint Farm

Written by Denis Stadler on . Posted in SharePoint 2010

Post Summary

The purpose of this article is to describe how to implement a medium SharePoint Farm – three-tier, four-servers.  Before going into details I would like to recommend you to download the following file: Topologies for SharePoint 2010.

If you want you can download this post as a PDF file – How to Implement a Three-Tier SharePoint Farm.

My SharePoint Topology

My environment is hosted on Windows Server 2008 R2 Hyper-V and consists of four servers: SQL, SPLive1, SPLive2 and an Application Server.

Basically the services in farm will be split according to the following table (please take into consideration only the production environment – highlighted with green):