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:-)

No Visual Studio designers for generic ViewController versions

XAF Controllers are technically descendants of the System.ComponentModel.Component class, primarily to be smoothly integrated with the Visual Studio design time features. The standard Component designer does not support generic classes due to a Visual Studio limitation: https://stackoverflow.com/questions/6877217/can-visual-studio-designer-show-classes-inheriting-generic-types 

This is a Microsoft functionality and we cannot do much about it on our side. So, if you have a class like this, and try to double click it or use the Enter key for it in the Solution Explorer, you will receive this error, which is expected here:

This has always caused support calls to us from day one and still causes them today. Check out this support article to learn more about this situation and our previous recommendations.

Starting with v17.2.6, we have removed the visual designer association from the base ViewController<ViewType> and ObjectViewController<ViewType, ObjectType> classes - they will always be opened directly in the Code Editor now. This should work fine in Visual Studio 2015, 2017 and newer versions. This does not work for Visual Studio 2013 and older versions and we decided not to investigate this further, because of the very low usage rate of these IDEs nowadays.

We believe that this new behavior is most expected here and really hope that it will not cause new questions😀. Originally, generic View Controllers were specially designed for users who prefer to do everything manually and want to have a more elegant and compact code. So, opening the Code Editor for such classes is naturally expected. Taking this opportunity, we also improved our online documentation to further promote generic View Controllers, since most of our Support Center answers, demos and docs use this concise code approach anyway.

My team and I are looking forward to hear from you on what you think of the new behavior.

New and updated help topics in version 16.2.4

Recently, Dennis has published a huge list of changes introduced in XAF documentation in the previous major update (16.2). In this post, I would like to overview another set of changes in XAF documentation introduced with the 16.2.4 minor update of XAF.

How long since you have seen the "Dictionary already contains ClassInfo ..." error for the Model Editor?

Old XAFers can remember this old sporadic issue caused by a Visual Studio bug that could not be fixed on the IDE side for years (learn more...). We were frustrated by it no less than our users, and this April (15.1.11+, 15.2.8+, 16.1+) we finally found a way to bypass this nasty behavior of an internal IDE assemblies cache on our side by changing the process of  loading assemblies at design time. This was quite a risky change, but so far our testing of many projects under various circumstances went well. We also have not received user reports on the original problem or other side effects with our designers since then (more than 8 months).

That said, I wanted to explicitly clarify with the XAF community whether it is really gone after our changes or not. Please leave a comment below on whether you have seen this error with the latest XAF versions OR you already cannot recall when it occurred last time. If this still bothers you, I would kindly ask you submit a ticket using the Support Center and attach a project where this behavior is stably reproducible, exactly as this kind guy did in the past.

My team and I look forward to hearing from you!

A sporadic Visual Studio issue with the incorrect Action constructor after modifying Controller (Finally bypassed in 14.2.4!)

Have you ever seen a situation when your Actions defined in the Controller designer worked well, but one day they disappeared from the application UI and were no event present in the Application Model? Unfortunately, we sometimes did, and so did our customers under certain circumstances. The difficulty of this situation is that this annoying behavior in the IDE was truly random and sporadic, as it all might work on the same machine and then fail without any reason under the same circumstances, with no environment changes. This behavior could be reproducible with both new and existing Controllers and Actions. Our Controller/Action/designers code was fine and the same issue could be reproducible even with the standard Component Designer and standard MS components, so it was eventually reported to MS Connect:

This problem was not massive, to be honest, but the reports the report count reached a reasonable threshold within several years... 

Since we still continue to receive reports from our customers on this behavior from time to time, which negatively affects their experience with our product, we decided to introduce a special "hack" on our side, which helps avoid this behavior. This fix successfully worked in our tests with the problematic virtual machines where we happened to semi-stably isolate this strange behavior. This improvement is available starting with version 14.2.4 and I recommend you upgrade to this version if you experienced this behavior in the past.

Hopefully, you will never experience this again, and Happy XAFing/holidays!

A small usability improvement to the new visual ListView designer available in v14.2

Thanks to our great customers and their feedback in this Support Center ticket we could make our recent addition to the Model Editor yet better. Starting with version 14.2.4, it will be much more convenient to view and configure ListView with lots of columns, because now the horizontal scrollbar will be displayed in this situation. A picture is worth a thousand words:

Of course, the live preview will also respect column sizes set in the property grid for each IModelColumn object.