Old entries in the XPObjectType table - YOUR FEEDBACK IS NEEDED!

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.

AccessViolationException at Microsoft.VisualStudio.Shell.Interop.IVsRegisterEditors.UnregisterEditor may occur in Visual Studio 2010, 2012

This sporadic design time error might go away in Visual Studio 2013, 2015, 2017 and newer.

Exception

Type: System.AccessViolationException
Message: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
StackTrace:
   Microsoft.VisualStudio.Shell.Interop.IVsRegisterEditors.UnregisterEditor(UInt32 dwCookie)
   Microsoft.VisualStudio.Shell.Package.Dispose(Boolean disposing)
   DevExpress.ExpressApp.Design.Core.XAFPackageV4.Dispose(Boolean disposing)
   Microsoft.VisualStudio.Shell.Package.Microsoft.VisualStudio.Shell.Interop.IVsPackage.Close()

We have been tracking this error for years from XAF users using https://logify.devexpress.com. We also received a few tickets, but could never replicate this behavior for debugging. Our attempts to log diagnostic information about this error did not help either. Well, it does not seem to relate to the DevExpress.ExpressApp.Design.Core.XAFPackageV4.Dispose method itself. There are also many non-XAF reports devoted to the same error, but different packages on the Web. https://www.google.com/search?q=Microsoft.VisualStudio.Shell.Interop.IVsRegisterEditors.UnregisterEditor+accessviolationexception

From the Logify stats, we know that this error occurs only with these two old Visual Studio versions. It seems that something got fixed in newer IDE versions. If you are on Visual Studio 2010 or 2012 and encountered this error at design time, consider upgrading your IDE - it's 2018 after all:-)

SQL Server-related methods of ModuleUpdater and pooled database connections

Before the end of this year, I wanted to inform you of some "home work" done by us to improve your XAF development experience with the ModuleUpdater API:

ModuleUpdater - CreateCommand and other SQL Server-related methods may throw NullReferenceException with pooled database connections

Another example of how Logify helps us improve quality and reflections on how it can help you even more

You might recall my previous post on how DevExpress Logify is used to deliver crash reports in demos, runtime and design time tools for many DevExpress products and technologies.

I wanted to share another real story and discuss an idea, which may improve your user experience as well.

06/09/2017, we fixed an issue Model Editor - Hidden items are lost after cancelling changes in the Customization Form (private). 

06/28/2017 we published v17.1.4 with these changes.

07/03/2017 (5 days later), we received the first Logify report about the "Unable to cast object of type 'DevExpress.ExpressApp.Win.Layout.XafLayoutControlGroup' to type 'DevExpress.XtraLayout.LayoutControlItem'" error, because our manual and automatic tests did not cover one scenario where the new code stopped working.

07/07/2017, we fixed our code and provided intermediate builds with the fix.

Since that fix, we published 17.1.5, 17.1.6, 17.1.7, 17.1.8 updates, but I still see the same reports in Logify from users sitting on the old v17.1.4 and v16.2.8 with that already fixed bug. For instance, one of our users had this crash 17 days ago, because he is still using that v17.1.4 from 06/28/2017:

Now the improvement idea to discuss with you.

Beware of the situation when a signed assembly with a business type used in the dashboard changes its version

I wanted to inform our Dashboard module users about a situation, which we missed originally:

DashboardObjectDataSource serializer fails to load a data source type when signed assemblies with a changed version are used

As you understand, it may occur only when target business types used in XML dashboard definitions with ObjectDataSource are from signed assemblies and the assembly version changes, e.g. when you deliver a new app version to the client:

 <DataSources>
    <ObjectDataSource ComponentName="dashboardObjectDataSource1">
      <Name>Object Data Source 1</Name>
      <DataSource Type="YourNamespace.YourObjectType, YourAssemblyName, Version=17.1.6498.1953, Culture=neutral, PublicKeyToken=YourPublicKeyToken" />
    </ObjectDataSource>
  </DataSources>

Currently, we recommend XAF application developers try a couple of solutions described in that thread, but they are not final solutions. We are currently reviewing them from the security point of view to make sure that the app won't be broken by passing another non-signed dll. For now, this does not seem to be the case, because business type information is obtained using the ReflectionHelper API from the already loaded assemblies, which are protected by the default .NET mechanisms. We just want to double-check or see if there are more suitable options. Ideally, I wish this to be working transparently for an application developer without the need to resolve any assemblies or types manually.

Your feedback is needed!

Have you experienced this behavior in your Dashboard apps? How do you currently cope with it? If there are existing solutions, share their details and also elaborate on their costs. Your feedback is greatly appreciated.

What's New in XAF 15.2 Documentation and general upgrade tips

As you probably know, in addition to the new great features the version 15.2 introduced, there are also various improvements to the learning materials that will allow you get the most of DevExpress products and become a better developer.

The XAF documentation changes we are the most interested in are listed below:

Concepts and task-based help

• How to: Hide the Edit Action Column in from a ListView in an ASP.NET Application
• Maps Module
• Maps Module Overview
• Use Raster Maps
• Geolocation Properties
• How to: Change the Map Marker Icon
• How to: Change the Map Settings Dynamically
• Display Areas on a Vector Map
• Display Bubble Markers on a Vector Map
• Display Pie Markers on a Vector Map