I am reviewing the priority of a quite dated SC item on the subject and wanted to ask the community for help. The problem may occur when old business class libraries exist in the application folder. By default, XPO tries to load them by the XPObjectType info along with the new versions. This may lead to a conflict at runtime or startup performance degradation. In the latter case, assembly type resolution may come at a cost (see the point 3.5 under How to measure and improve the application's performance).
Why are we hesitating to remove old XPObjectType entries by default?
1. Removing old XPObjectType records affects other apps accessing this database and is serious. Outdated service table records may relate to business class records too (inheritance mapping is in use very often). So, deleting them will lead to foreign key constraint violation. Creating a sophisticated generic solution for this is not easy task.
2. XPObjectType table updates are safe only with the full database and application knowledge. Users possessing this knowledge can use ready options like the ModuleUpdater.UpdateXPObjectType method (SQL Server-specific) shown in the How to: Handle Renamings and Deletions of Business Classes and their Properties article. We also demonstrated a db-server agnostic updater in the aforementioned ticket.
3. We help XAF developers detect this fact by writing log messages. Check out your eXpressAppFramework.log file for the "Resolve the 'DevExpress.ExpressApp.Workflow.v11.1' assembly" and similar messages referring to outdated DevExpress assemblies. Of course, a developer or DBA can preview the XPObjectType table using database engine tools.
4. Old application assemblies living within the new application folder is unexpected in itself. At least, I would instinctively always prefer a fresh Windows install over an update. Even though we are aware of some specific scenarios (e.g., with plugins or locked assemblies), it is still easy to install the new application version into the new folder. This natural action will avoid these risky circumstances completely.
5. Finally, we heard less or almost nothing about this behavior lately. Most likely, this is because an XAF app stores user settings in the database and not in a file system by default and thus the point #4 is simpler.
Your feedback counts!
Regardless of the reasoning above, I want to learn better on how it looks from your side. Please answer two simple questions here in comments or use the https://www.devexpress.com/ask service:
Q1. Did you ever notice negative effects from the outdated type and assembly references in the XPObjectType table?
Q2. If so, describe your problems and use-case scenarios in greater detail. Also, comment on their frequency (e.g., once, every year, etc.) as well as on your current solution implementation and maintenance costs, if any.
In advance, thank you very much for your help! Hopefully, I am not looking this way from your side😜
