After the update to version 1.5.2 my WPF 4.0 application is no longer closed.
See the simple example in the attachment. Example works fine with CaliburnMicro 1.4 and has infinite wait with 1.5.2
Comments: This is not as easy as it seems. The method looks like this (simplified for WPF only): ``` C# public static void OnUIThread(this System.Action action) { if (CheckAccess()) action(); else OnUIThreadAsync(action).Wait(); } ``` `OnUIThread` executes an action synchronous on the UI thread. When you are already on the UI thread it is directly executed. If you are on another thread the action is dispatched to the UI thread and we wait for the call to finish (synchronous). In this issue the dispatcher is already shutdown (window is closed) and afterwards the background thread tries to dispatch an action to the UI thread what fails. The question is if the calling could can rely that the action was executed or not. As 'OnUIThread' is synchronous the answer has to be YES. If you don't need this you can use `Execute.BeginOnUIThread` in your background thread. It is asynchronous without a Task object to wait for. Only fire and forget ;-)
See the simple example in the attachment. Example works fine with CaliburnMicro 1.4 and has infinite wait with 1.5.2
Comments: This is not as easy as it seems. The method looks like this (simplified for WPF only): ``` C# public static void OnUIThread(this System.Action action) { if (CheckAccess()) action(); else OnUIThreadAsync(action).Wait(); } ``` `OnUIThread` executes an action synchronous on the UI thread. When you are already on the UI thread it is directly executed. If you are on another thread the action is dispatched to the UI thread and we wait for the call to finish (synchronous). In this issue the dispatcher is already shutdown (window is closed) and afterwards the background thread tries to dispatch an action to the UI thread what fails. The question is if the calling could can rely that the action was executed or not. As 'OnUIThread' is synchronous the answer has to be YES. If you don't need this you can use `Execute.BeginOnUIThread` in your background thread. It is asynchronous without a Task object to wait for. Only fire and forget ;-)