Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

What are the best practices for saving application settings in a Sharepoint application?

Would anyone save the settings in the web.config's appsettings?

What about saving them in a SharePoint list?

Any other ideas? pros? cons?

share|improve this question
add comment

5 Answers 5

up vote 8 down vote accepted

Here is a list that I compiled with six different ways (and a few alternatives in the discussions).

Six ways to store settings in SharePoint

share|improve this answer
    
hey thats a good blog post right there! Added to delicious :-) –  Anders Rask Feb 3 '10 at 14:44
    
thanx- The property bag option is getting more interesting now with SP2010 and upgradeable features! –  Wictor Wilen MCA MCM MVP Feb 3 '10 at 14:48
add comment

As is often the case when developing with SharePoint, the answer is really "it depends"!

If you are configurating webparts, often the best way to configure them are using custom properties and either use UI or .webpart xml file to configure them.

If we are talking connection strings for InfoPath, theres data connection libraries

Connection strings could be stored in web.config connectionstring settings, but could also be stored in the property bag for a site or a list: SPPropertyBag.

For features you can store properties in the feature xml. Example here.

For timerjobs you can store it in the object itself, since it per definition is a persisted object and hence stored in the persisted configuration cache. See an example here and here how to store this kind of data.

As you can see it is not easy to give one general answer to your question :-)

share|improve this answer
add comment

I'm not remotely biased of course, but I think my Config Store solution is a good option (based on storing config values in a list). In addition to what I list on the codeplex site, there are some later enhancements such as allowing hierarchical config and providing an expression builder for use in ASPX markup, so it has a lot of features which can be useful. It's unlikely to be the right choice for every scenario, but if a list seems like the right approach it should be a much better starting point than nothing due to things like the caching layer.

Suggest also checking out Microsoft's SharePoint Patterns & Practices Guidance on this - in the PDF they have a good table comparing some options (they also mention my Config Store solution, but I promise that's not the only reason I think it's good info!)

share|improve this answer
    
So you think just because you wrote it you deserve the votes do ya? I got here first buddy... ;-) –  Charles Lee Feb 4 '10 at 12:56
    
LOL :) Psst, I'll cut you in, don't worry about it! –  Chris O'Brien - MVP Feb 4 '10 at 15:06
add comment

I would recommend you take a look at Chris O'Brien's SharePoint Config Store:

http://www.codeplex.com/SPConfigStore

share|improve this answer
add comment

Generally, my "rule-of-thumb" is that if it is "application (site) specific" then store it in a list. If it is something that needs to be "tuned" by an administrator rarely and applies to multiple "applications" then store it in the "web.config".

One thing, if you do store settings in a list - ensure versioning is turned on - I just had a situation where a vendor was blaming my team for making changes - we did not, heck at the time we did not even know their settings were stored in a list.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.