During a code review today at work, the concept of property bags got brought up, and there are a lot of points of confusion that come when you begin looking at property bags. So what is a property bag?
Property bags become important when you begin looking at SharePoint Features, since for each SharePoint Feature that you have, they will have their own property bag. In essence, like a lot of sections of SharePoint development (like resource files), a property bag simply contains a series of name/value pairs that correspond to the Feature properties, which are formatted with System.String. This is opposed to other type of property bags that you may find throughout Windows development like when programming against SCOM 2007, which will use things like a VariantType enumeration in order to specify a variant object. It’s all System.String in SharePoint Feature files.
Property bags are pretty helpful when you are doing things like holding data that is going to be environmentally distributed while it is written to / extracted from, and isn’t subject to much change.
You can expose the properties of a feature through the property, property. Yeah, that is kinda of confusing. But, just know that there is a property, property, for each SPFeatureProperty that is in the SPFeatureProperty collection, which as you can guess, holds a collection of SPFeatureProperty objects! You can look at the properties of a Feature by calling the properties, property of a Feature:
Then you can call each property by using SPFeatureproperty and pooling out the Name / Value pair data.
Please do add anything that extends this concept further, I would be interested in hearing other peoples thoughts on the subject.