ASP.NET 配置文件版本控制？
ASP.NET 配置文件如何处理版本控制？我知道因为数据是序列化的，这可能是一个问题，而表则不是。
它会抛出某种序列化错误吗？
示例：我将 v1 对象存储到配置文件中。我使用新的 v2 版本更新了我的 Web 应用程序，但数据库仍然包含 v1 对象。
当我尝试将 v1 对象反序列化为 v2 对象时会发生什么？这个问题的最佳解决方案是什么？
How does ASP.NET profiles handle versioning? I know because the data is serialized this could be a problem where with tables it is not.
Will it throw some sort of serialization error?
Example: I store a v1 object to the profiles. I update my web application with a new v2 version but the database still contains v1 objects.
What will happen when I attempt to deserialize the v1 objects into the v2 objects? And what are the best solutions for this problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通常，ASP.NET 将配置文件数据视为属性包 - 因此它可能会跳过某个属性（已存储在数据存储中）但从配置中删除。同样，对于新添加的属性，它将使用默认值。现在，属性的类型也很重要 - 如果属性类型是您的自定义类，那么其序列化将由 XmlSerializer 或 BinaryFormatter 处理。 XmlSerializer 是默认值，通常是一个宽容的序列化器（缺少的属性将被跳过等）。您可以使用属性来控制 xml 序列化。对于 BinaryFormatter，它与运行时序列化相同，如果您希望支持版本控制，最好实现 ISerialized 并处理任何版本控制问题。我不确定如果您拥有某种类型 A 的配置文件属性，然后删除该类型，会发生什么情况。我的猜测是你应该得到一个错误，但我不确定这一点。
我通常更喜欢汇总自己的实现来支持用户配置文件功能，因为
可以是独立的（这是可能的
通过自定义在 ASP.NET 配置文件中
配置文件提供者）
分层应用程序和配置文件数据
也可用于任何非网络
如果需要的话，客户
轮子并付出一些额外的努力，
对于任何具有以下功能的软件来说，它的价值
保质期2-3年以上。
存储/检索配置文件数据
数据存储。
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
can be independent (this is possible
in ASP.NET profiles by custom
profile provider)
layered application and profile data
is also available to any non-web
clients if needed
wheel and having some extra effort,
its worth for any software that has
shelf life of more than 2-3 years.
store/retrieve the profile data from
the data store.