Typically ASP.NET treats profile data as a property bag - so it would probably skip a property (that has been stored in data store) but deleted from configuration. Similarly, for newly added property, it would use the default value. Now, type of properties will also matter - if property type is your custom class then its serialization will be handled by either XmlSerializer or BinaryFormatter. XmlSerializer is a default and its generally a tolerant serializer (missing properties will be skipped etc). You can use attributes to control xml serialization. In case of BinaryFormatter, its same as runtime serialization and if you wish to support versioning, its best that you implement ISerializable and handle any versioning issues. I am not certain what would happen in a case where you have a profile property of some type A and then you delete that type. My guess is that you should get an error but I am not ceratin about it.
I typically prefer to roll up my own implementation for supporting user profile feature because
- Things such as versioning etc can be controlled as per my liking
- Choice of store and storage schema
can be independent (this is possible
in ASP.NET profiles by custom
profile provider)
- It can be easily put into the
layered application and profile data
is also available to any non-web
clients if needed
- Although it means re-inventing the
wheel and having some extra effort,
its worth for any software that has
shelf life of more than 2-3 years.
- I can control precisely when to
store/retrieve the profile data from
the data store.