Simplify Custom UI - remove Caliburn.Micro

[smaudet]

Question/suggestion,

What is Caliburn Micro really providing? Can we just get rid of it?

Possibly it is just the difficulty of debugging UI at an admin level in a mixed-mode setting, possibly it is that windows forms + wpf is just bugged, but Caliburn seems like it is adding another layer of (unwelcome) complexity to the insanity of a stack that is MSI...

As mentioned in another discussion here previously, there is something wrong with the hosted WPF, where under the right circumstances the wpf window can't initialize correctly. Well, now the features dialog has gone and broken (some update, and I was making updates to my installer).

Maybe there is some better way of debugging what is happening in the WPF/WinForms that stuff like bindings don't work and I can't inspect the UI at all (with snoop/microsoft blend, it all crashes and burns horribly), but it seems like Caliburn is just some ancient library that doesn't provide much except another layer of hell to debug...

[oleg-shilo]

Sorry for the delay. was engaged with other projects.

It's a good question that does not have a good answer :)

Caliburn Micro is an MVVM that helps orchestrate the dialog initialization under WPF. It is rather a brilliant lightweight lib that worked really well for me for years (and never failed). So I included it in the dialog to minimize the overhead of the manual binding. It does not force the user to use (deal with) it in the user-defined dialogs and it does not prevent the user from using any other lib of this sort (MVVMLight) or going with the manual binding.

Though there is a serious "however" in this story.
I wouldn't make the same Caliburn decision today.

The fact that Caliburn introduced the breaking change for their .NET 4.7 forced me to pack two versions of the DLL, to do the runtime dependency resolution. And since there are some hiccups with WPF hosting, having this extra dependency does not help.

Thus I am converting this to the enhancement request and will address it at the next opportunity. It should not be long.
It's a pity, that I will need to resort to manual binding and also impose it on the VS template users for the templates with the dialog sources. But I agree, it's better not to have this dependency.