Where to place configuration settings for event handlers?
I have thought about it and came up with a few options:
Place config information in the event handler registration info
Every time you register an event handler with a list you can specify data specifically for that registration. This can be done with a feature, or using code (see my utility pack for an easy way to do that)
- Can be deployed using a feature. We can have different config per list.
- We only have a seperate config per list (no one place to manage all lists).
- Limited to 256 characters.
- You will need to run code to change the configuration.
Place config information in the web.config <appSettings> section
I was surprised to find that the event handlers get access to the web.config as if they were web applications. Cool!
- One place to manage per web application. can be deployed using a web application feature and some custom code (http://blog.tedpattison.net/Lists/Posts/Post.aspx?ID=4)
- Hard to deploy every time you create a new web application in the farm. This can be resolved by creating a feature and stapling it at the farm level (scope is webapplication) that modifies the web.config to include the section you want, and setting some defaults - so that the event handler finds what it is looking for when a new web application is created.
Place config information in a settings file on the file system
- One place for the enitre farm, can be deployed using a solution package
- Location is hard coded in the event handler (unless we use this approach mixed with option one!).
- Folder must allow users to read, or impersonation will be required.
Place config information in a settings file in the GAC, next to the assembly
I used this a few times. You can put a file right next to the dll, and use a helper class in the dll to deserialize it and read the values.
- one place for the enitre farm, no hard coding of location.
- Use Mide Woodring's AssemblySettings class to read from it. can probably be deployed as a farm feature
- Every time a new dll version is entered, the config will be deleted and will have to be added again.
Place config information in a document library\list in the root sharepoint site of a site collection or in the central administration site or the shared services site for that web application
- Deployable as a feature at the site collection level
- still requires custom code to get the config.
- performance hit on reading the configuration (can be minimized with caching).
- (if root site collection option) Only supports site collection level configuration.
Special thanks to Reza Alirezaei who pointed out some spelling mistakes and commented on the web.config section.