Caliburn.Micro for Windows Forms and Visual WebGUI

On a post some 3 years ago, answering my own question "Can we port Caliburn.Micro to WindowsForms?", I said "Not yet. Several problems have to be solved first" and went on about all the issues to be solved. It turns out most problems were already solved by Dan Durland's port, that was hidden among the 100+ forks of Caliburn.Micro.

The port isn't complete and there are some issues, but overall, is a very good port.

• One of the main issues was the lack of DependencyObject and DependencyProperty classes outside the WPF world. These classes are partially implemented, just enough the make the port easier to do.

• Plain System.Windows.Forms events replace the functionality that is provided by the System.Windows.Interactivity Trigger stuff (EventTrigger and TriggerAction) used on regular Caliburn.Micro.

• As ToolStripItem descend from System.ComponentModel.Component (and not from System.Windows.Forms.Control), a ToolStripItemProxy control is provided. The framework manages the life cycle of this control automatically, so you can ignore it altogether.

• On the other hand, you can't ignore the provided ContentContainer control that replaces Panel. It knows about what ViewModel it is bound to, and is intended to host the UserControl that you want to load on your shell Form.

• The message.attach feature is implemented as a string on the Tag property of the Button or whatever System.Windows.Forms.Control descendent you want.

If the latter feature implementation proves to be a problem (some people might use the Tag property for other purposes), the plan B is to implement this feature as a DependencyProperty.


The port doesn't support some very interesting Caliburn.Micro features, all in the Action parameters area:

1. Support for SpecialValues parameters ($eventArgs, $dataContext, $source, $executionContext and $view)
2. Support for $this parameters
3. Support for object.property parameters
4. Binding to object.property parameters
5. Guard method re-evaluation on object.property change

Nonetheless, and repeating what I said before, I would say that overall, it is a very good port.

The MVVM FX project took Dan Durland's port as a working base and improved on it. All the issues outlined above were solved. Point 3 was solved with the help of MVVM FX own binding library, that is based on Truss by Kent Boogaart.

MvvmFx.CaliburnMicro went a step further and provides interesting features that are absent on regular Caliburn.Micro:

• Support for $this.property parameters
• Binding to $this.property parameters
• Guard method re-evaluation on $this.property change

There is a feature that might prove interesting and is hold back until proven necessary:

• Support for SpecialValues.property parameters

The Visual WebGUI project follows quite closely the Windows Forms implementation, but addresses two major differences:

• There is no such thing as a UIThread under WebGUI.
• A VWG application starts by building a Form (no Program.cs file) while Windows Forms applications uses Caliburn.Micro to build the shell Form.

All the samples have two projects: Windows Forms and WebGUI. Both projects share the exact same ViewModel

While Dan Durland's port is based on Caliburn.Micro version 1.3.1, the MVVM FX source was updated to 1.5.2, including all post 1.5.2 fixes that were applied before the regular Caliburn.Micro was ported to BCL.

A final note to say that MvvmFx.CaliburnMicro is formally in beta stage, but is stable enough for you to start developing with it. As soon as the samples are ready, it will be release, both on Codeplex and on NugGet, both for Windows Forms and Visual WebGUI.