Typically, ASP.NET treats the profile data as a bag of properties - so it will probably skip the property (which was stored in the data store), but removed from the configuration. Similarly, for a newly added property, it will use the default value. Now the property type will also matter - if the property type is your custom class, then its serialization will be processed either by XmlSerializer or BinaryFormatter. XmlSerializer is the default and its generally tolerant serializer (skipped properties will be skipped, etc.). You can use attributes to control xml serialization. In the case of BinaryFormatter, it is the same as serialization at runtime, and if you want to support version control, it is best to implement ISerializable and handle any version problems. I'm not sure what happens when you have a profile property of some type A, and then you delete that type. I assume that you should receive an error message, but I am not sure about that.
I usually prefer to minimize my own implementation to support the user profile function, because
- Things like version control, etc. can be controlled to your liking.
- The choice of storage and storage scheme can be independent (this is possible in ASP.NET profiles by a custom profile provider)
- It can be easily inserted into a multi-level application and profile data is also available for any non-website clients if necessary.
- Although this means re-creating the wheel and with some additional effort, its value for any software that has a shelf life of more than 2-3 years.
- I can precisely control when to store / retrieve profile data from the data store.
VinayC
source share