R – Storing Feature Configuration within Sharepoint

sharepoint

i have a Sharepoint feature that essentially extends Lists with a new feature, using a List receiver. For each list the feature is attached to, i need to store some configuration.

Now, the first thing that came into my mind is the obvious solution: Have a global list. That works of course, but I wonder if there is some way to store feature-specific configuration in a hidden place? Not that it's sensitive information, but I don't want to clutter the Users Display with too many lists. I believe I can hide lists, but at the same time I wonder if sharepoint allows me to use it's database?

I am not talking about just using ADO.net to access the db directly (which is a big no-no with Sharepoint), I am thinking about some officially supported mechanism.

Best Answer

SPLists, unlike som other objects, do not have property bags, however all lists in a SharePoint site has a correlating SPFolder object stored in the RootFolder, and an SPFolder object has a property bag where you can store custom configuration data for the list.

Edit: I've written an article that shows how to use SPFolder to store custom list data if you are interested.

Related Solutions

R – SharePoint Development / Production Environments

There are really two (more?) levels to SharePoint "development". You have the code which gets deployed to the server, such as web parts, content types, workflow actions, etc. This works relatively well in terms of deployment and best practices.

Then you have your example, which is more of a customization of site instances. What we've done when we had to customize a calculated field in the Portal's Site Directory list, is to try and tweak the changes in development. Then write up detailed instructions of the customization to be made, and have a separate person with appropriate permissions use those instructions to make the change on an integration (staging) server. Then have the same person makes the changes live on the production.

I'm not sure if your changes are susceptible to this approach, but it's worth considering.

Then we have another site which is heavily customized with SharePoint designer, and that one we work live on.

R – SharePoint and deployment of global.asax code

I don't know about "best practice", but I would be quite keen on making the edits via code in the feature reciever.

With a line that backs up the file for later restoration.

For logging, we have used Scott hilliers code here to create a trace provider to log with.

Works a treat.

I should clarify that we use a static readonly wrapper for the trace provider

static readonly Log instance = new Log();

that registers itself with the code

SPFarm farm = SPFarm.Local;
Guid traceGuid = farm.TraceSessionGuid;
unit result = NativeMethods.RegisterTraceGuids(ControlCallback, null, ref traceGuid, 0, IntPrt.Zero, null, null, out hTraceReg);
System.Diagnostics.Debug.Assert(result==NativeMethods.ERROR_SUCCESS, "TraceRegister result = " + result.ToString());

Gah!

This then gets instanciated only once and we use the destructor to unregister it.

Best Answer

Related Solutions

R – SharePoint Development / Production Environments

R – SharePoint and deployment of global.asax code

Related Topic