A must read blog post -everything about AllowUnsafeUpdates

If you are a sharepoint developer, you have to read this one: What you need to know about AllowUnsafeUpdates. While you are there, take the time to register to that blog. Hristo Pavlov looks like a blogger to watch for!

Tweet - writing code that accesses a site in another application pool

sorry for the tweet - no time to explain.
<TWEET> If you are writing code that accesses (or potentialy accesses) a site in another application pool, make sure that the application pool account for the current application pool has database permissions on the database for the other application. otherwise - you'r objects will not get created. </TWEET>

Event handlers configuration settings best practices

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)
PRO:

1. Can be deployed using a feature. We can have different config per list.

CON:

1. We only have a seperate config per list (no one place to manage all lists).
2. Limited to 256 characters.
3. 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!
PRO:

1. 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)

CON:

1. 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
PRO:

1. One place for the enitre farm, can be deployed using a solution package

CON:

1. Location is hard coded in the event handler (unless we use this approach mixed with option one!).
2. 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.
PRO:

1. one place for the enitre farm, no hard coding of location.
2. Use Mide Woodring's AssemblySettings class to read from it. can probably be deployed as a farm feature

CON:

1. 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
PRO:

1. Deployable as a feature at the site collection level

CON:

1. still requires custom code to get the config.
2. performance hit on reading the configuration (can be minimized with caching).
3. (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.

Great MSDN developer article - Development Tools and Techniques for Working with Code

There is a new article in MSDN which enraptured me. It is a magnificent summary of what development in sharepoint is all about, with example on how to do sample tasks.
It is in two parts, and is from my fellow MVP Patrick Tisseghem, (from U2U, Patrick is one of the authors of my favorite sharepoint developer utility - the CAML Query Builder) Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 (Part 1 of 2)
Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 (Part 2 of 2)