The problem I encountered with this was that I was trying to set some Search Center settings on a newly created Site Collection, and their capitalization was being persisted wrongly:
newRootWeb.AllProperties["SRCH_ENH_FTR_URL"] = settings.SearchCenterUrl;
This would be persisted as lower case – which was wrong. Lower case capitalisation isn’t the same upper. Nice.
I found a good post about this from Trent Foley, who advocates setting the same key for both Properties and AllProperties. I’m going to shamelessly plagarise a bit, ‘cos I don’t know where he found this, but it’s important:
Apparently the AllProperties is meant to replace Properties, but Properties was left in place for backwards compatibility. Here’s where things get wicked …
The unconventional PropertyBag data type stores its keys in all lowercase, thus not supporting case-sensitive keys, while the conventional Hashtable does support case-sensitive keys. On top of that, while entries added to Properties get propagated to AllProperties with a lowercase key, entries added to AllProperties do not get propagated to Properties.
Well, I was using properties that I know will only be in the AllProperties collection. I used Reflector and checked the SharePoint page for setting these settings – it uses AllProperties. So how the hell could it be wrong?
In my code, I was setting other properties on the site collection – and these were in the Properties collection. What I found was that for the capitalized AllProperties keys, I needed to set them and update both the site and properties collection before I set my other properties.
Genius. So the capitalization in my two property bags depends on the order in which I set and update the values to go in them.