So, like many SharePoint objects, the SPWeb object has a property bag. Unlike many, it has two – Properties and AllProperties.
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.
newRootWeb.Update(); newRootWeb.Properties.Update();
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.
Andy Burns' Blog 
Thanks a lot for this! This saved us a lot of work.
Something really needs to be done about the properties API 🙂
I’m intrigued.
Given that this is an extremely lousy implementation that force an unfair constraint on your code, why didn’t you just work without capitalized keys? Surely your code could have been refactored to work with case insensitive keys using the Properties collection.
Sometime you just accept that SharePoint has some quirks and live with them 😉
Soeren – It wasn’t my properties that I was trying to set, but standard SharePoint ones. For example, the Search Center URL as shown above. SharePoint defines this as being upper case, so no, there wasn’t any way I could just use lower case. And I couldn’t just use Properties, as it would make my keys lower case – thus breaking things again.
You’re absolutely right for my own keys, though – I always try to use properties, and lower case keys. It’s just that sometimes, SharePoint’s settings need an uppper/mixed case key.
It’s also worth noting that this might cause some problems in Sandbox solutions for SharePoint 2010. There may also be other approaches if you use SPWeb.Properties.AddProperty()
I must agree with Soren here.. And, yes, I am not drunk… This is crazy and after consideration, I must say, I rather use SPWeb.Properties object to cover both scenarios, if you don’t mind lowercase…
This is rare scenario where I may against MS best practices or newer approach..
Yup, I agree with Soren too – just in this particular case, I was trying to set a standard SharePoint property in the bag that *had* to be capitalized.
Do you happen to know if these properties surface in sharepoint search as crawled properties? I doubt but wanted to check here…
Yeah, I don’t think so, I’m afraid.
I was looking for the same thing as Nik. Not sure how to get a managed property on a SPWeb so it’ll show in search results…