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

Usability change for SingleChoiceAction with a single visible sub-item - YOUR FEEDBACK IS NEEDED!!!

We have incorporated the usability improvement from my past post in v18.1 by default. It affects SingleChoiceAction with ShowItemsOnlyClick = False and ItemType = ItemIsOperation  and should improve UX for the majority of our users. We also want to enable the same behavior in an upcoming minor update (e.g., v17.2.6 or next). Our team would appreciate your feedback to help us decide on the latter.

Questions/Risks

While this behavior is always desired for the New & Clone Actions, because their meaning is clear from the context, certain custom and built-in Actions like Show In Report, Change State may be affected when they keep only a single sub-item. Examples:

17.2.5 and older versions:

18.1 (and 17.2.6+, if the majority likes it):

Notice that we've replaced a dropdown/triangle glyph with a simple button. We believe that this visual change is still not breaking (and thus is acceptable for a minor version), and it all is more logical than it was before. Before, when ShowItemsOnClick = False, you could still press the SingleChoiceAction's button blindly, i.e., without expanding its items using the triangle glyph. To help you avoid mistakes, the button is now displayed in the ChoiceActionItem's tooltip. You can also control the default Action item behavior using the DefaultItemMode property. If you do not like the new behavior, you can always set ShowItemsOnClick = True in the Model Editor.

Question: Are you OK to have this new behavior as default in v17.2.6+ too? 

Please answer with +1 or -1 with comments in this post. If you need to test your real apps live before making a decision, I can provide you with v17.2 or v18.1 hotfix builds. Thanks for your help in advance.

UPDATE:
Thanks to everyone! With v17.2.6, this behavior is enabled by default.

Learning through reading the source code

I will start this post with the new Visual Studio 2017 function, which I hope will be helpful for XAF developers too. I have both RTM and Preview versions installed, but I am mostly using the latter one for testing. The new function I spotted in their change logs is called "View decompiled source definitions instead of metadata (C#)".

As you can guess from its name, it changes the very often used "Go To Definition" command (F12) so that it displays the actual code of a C# type or member who's source code is unavailable - very useful and convenient, IMHO. It is decompiled using ILSpy, the tool I have already been using for years as default program association for opening *.dll files -  partially the reason of why this news got my attention. This experimental feature is new in Visual Studio 2017 version 15.6 preview 2+ and it must be turned on explicitly using the Tools > Options  >  Text Editor > C# > Advanced > Enable navigation to decompiled sources menu item. 

Customization Forms and Model Editor Improvements - XAF v17.2.6

Customizing Views layout, e.g., making certain fields visible, changing their locations is something that XAF developers usually learn and appreciate from day one. That is because you can drastically change the UI of your app by just moving the mouse and without any coding and recompilation, also at runtime. 

The next maintenance release (v17.2.6) should come with a few minor improvements to the customization forms in DetailView, ListView and the Model Editor, which we hope will be welcomed by both developers and end-users as well.

Beware of the failures when uploading JPEG/JPG images using the System.Drawing.Image type properties - XAF ASP.NET WebForms v17.2.5

I want to draw your attention to the T604395: Web - JPEG/JPG images cannot be uploaded to properties of the System.Drawing.Image type

 issue, which is already fixed in XAF v17.2.6. 

We apologize for the inconvenience, and if you cannot wait for the hotfix or did not plan to spend additional time on upgrade right now, please consider using the workarounds.

Important notes and workarounds

From v14.2, Image Property Editors (both WinForms and ASP.NET) support images saved as byte array objects (in addition to previously supported System.Drawing.Image objects). This allows us to significantly decrease web server memory consumption because the byte array can contain an image in a compressed format and the server does not have to unpack it. The previous approach with the System.Drawing.Image type property is still supported, but we recommend that you migrate to the byte array storage to improve performance. Refer to the BLOB Image Properties in XPO  and How to change the image property type from System.Drawing.Image to byte array help topics for more details. 

Minor improvements to the ConditionalAppearance and ViewVariants modules - XAF v17.2.6

I also wanted to inform you of some "home work" done by us in v17.2.6 to improve your XAF development experience with these modules:

GridListEditor - An appearance rule has no effect in the new item row until a value is entered into any cell
View Variants Module - ListView variant always takes the DataAccessMode value from the root node instead of own model differences, which may cause an exception due to an incompatible ListEditor type

While the first scenario is quite specific (we heard about it from our largest XAF customer and a few others), the second one was likely encountered if you use the ViewVariants module. For instance, when having one variant as a grid operating in server mode while having another variant as tree, pivot, scheduler or whatever ListView editor that does not support server mode. In the past, this unsupported configuration could cause an exception at runtime. Starting with v17.2.6, it all works as the majority our users expect - at least we believe so based on the feedback we received. The online documentation on the ViewVariants module will be updated accordingly by release time, of course. Finally, many thanks to Dave Hesketh, Martin Praxmarer, our MVPs, as well as other customers for bringing this to our attention.

If you cannot wait for the next maintenance update (v17.2.6) to test both things, install this night build: DevExpressNETComponents-17.2.exe

As always, my team and I are looking forward to hearing what you think, even on such small things and maybe others that could make your life a bit easier.

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.

Faster opening of a DetailView with lots of items - XAF WinForms v17.2.6

How big is the DetailView in the question? 

Well, in the T581043 ticket's test project, there are 250 editors in the detail form layout. Big enough, huh?

How much we could speed it up? 

On our powerful test machines, the time to open DetailView with just plain editors (no layout groups or tabs) has dropped from 3 seconds to almost 1. In real world applications, time to open a detail view depends on the application configuration (controllers, data, collection properties, calculated fields) and deployment specifics.

If you cannot wait for the next maintenance update (v17.2.6), install this night build: DevExpressNETComponents-17.2.exe

My team and I would be interested in hearing whether it is something you and your clients will notice too or if there are any problems with that new build. Thanks in advance.

Regards,
Dennis

P.S. If you already migrated to XAF v17.2, make sure you set XafApplication > OptimizedControllersCreation to True as well (read the prerequisites in the docs, first). The How to measure and improve the application's performance article may also help your app perform faster (magically, just after looking at it😜), so check it as well in case of problems in other scenarios.