SharePoint Configuration

All ASP.NET developers are used to write the value set in the web.config of the direction of programming logic at runtime. This practice has always made much sense to store things that change depending on where active databases (such as web services, etc) will live production time to come.

The hard part comes when you need to store the configurable settings that change the behavior of your code, but do not apply to other systems significantly. An example of a configuration option would be a magic number that is important in determining the status of a piece of data on your system, but is completely useless for the rest of the world.

While you can get away with storing values (such as magic numbers) in the web.config for ASP applications. NET standard of the majority, do it with SharePoint is a major no-no. SharePoint can overwrite sections of the website. configuration is not compatible with WSP / features when making solution deployments, and does not want to risk their vanishing values. It also goes without saying that the less cluttered you can have the web.config, the better - is complicated enough as it is.

So, if not in the web.config, how and where to store the values to configure custom code for SharePoint, and how it has come about recovery safely and efficiently?

You need two components:

• An XML document (stored in a familiar place - a document library is ideal) to store configuration settings
• A class in the cache, and then find the values at runtime

Here is an example of what the XML document should look like (You'll notice that looks identical to the node in a Web.config file standard):

<?xml version="1.0" encoding="utf-8"?>
<appSettings>
  <add key="FeedCacheTime" value="300" />
  <add key="DataInProcessId" value="92" />
  <add key="BuyoutThreshold" value="42" />
</appSettings>