This is the issue I promised in https://github.com/elmish/Elmish.WPF/pull/201#issue-402463416 that I would create.

Application.Current in https://github.com/elmish/Elmish.WPF/blob/3f0d3552203dcf3152f1088014ee608f2926f8a9/src/Elmish.WPF/ViewModel.fs#L199 was null when processing an initial state as described in #200. Indeed, this property is static with a private setter. The fix in PR #201 implies to me that the constructor of Application sets that static property (probably like Current = this). So that PR is a bug fix, but I also believe it does not satisfy the principle of least astonishment. I mean, look at how https://github.com/elmish/Elmish.WPF/blob/3f0d3552203dcf3152f1088014ee608f2926f8a9/src/Elmish.WPF/Program.fs#L36-L40 creates an Application instance and then throws it away. Very unexpected if you ask me.

Instead, I would prefer if we accessed the current Application instance in a way that I could statically verify in the Elmish.WPF code. There is more than one way to achieve this. Here is the way that I think is best.

We could implement the F#-equivalent of a static constructor to initialize a static let-bound Application instance like

type CurrentApplication()
  let value =
    let current = Application.Current
    if isNull current then Application () else current

Then we replace all references to Application.Current with CurrentApplication.value. As always, naming is impossibly hard, so we could certainly go with better names.

Thanks for sharing @JDiLenarda.

While investigating this bug, the thought about which Dispatcher instance to use crossed my mind, but I don't know the difference between using one vs another.

My guess is they’re the same, at least as long the program is launched in a STAThread.

https://stackoverflow.com/questions/20025143/application-current-dispatcher-vs-dependencyobject-dispatcher-for-ui-thread-acce

http://dotnetpattern.com/wpf-dispatcher