Storing farm level data for a web component

I've built a SharePoint user control (not a web part) and am deployi开发者_Go百科ng it via Solutions, Features, etc.

It's a commercial component and I want to be able to store license information once it's registered. I've got all the licensing stuff down and working, however, I am trying to find a "global" (i.e. farm level) place to store the information (so it works on multi-server farms).

This is intended to be a commercial component so I have no control over security policies, application pool accounts, etc. I need it to work without admins needing to reconfigure their farms.

I've considered:

• Web.config - best option so far, but have read that Windows UAC can interfere and changes may not always be applied.

• Hierarchical Object Store - Several security gotchas - Namely app pool needs access to Config database (which many environments won't allow)

• Root site property bag - Possible. I can update all the Root Sites Properties at the time of registration, but what happens when new web apps are created? User has to register component for each web app?

• Registry, file system - Not persisted across servers

• Custom DB - Seems like a lot of places for this to fail.

I know other commercial vendors are doing it somehow.

Any ideas?

Web.config - best option so far, but have read that Windows UAC can interfere and changes may not always be applied.

There are many many different opinions about putting your configuration stuff in web.config. Personally, i would NOT recommend it, because SharePoint is automatically pushing changes to it and you can't really control what's going on.

I've had similar requirements, but at a SiteCollection level. What i did was creating a simple custom list with 2 columns (Key, Value) at the root of my SiteCollection. Within my code, i hardcoded the name of the list and used elevated privileges (because i set the list permissions to admin-only) to access the values i needed.

You could basically do the same, but not at the root of the SiteCollection level, but in the Central Administration. This way, you can access the configuration list from anywhere within SharePoint.

Another idea would be setting up a simple configuration database and then use a custom web-service (which is deployed within SharePoint) to get it's values. However this adds quite a lot of overhead to such a "simple" task and will get you in a lot of trouble without proper exception handling/logging.