The previous behaviour was to raise an exception unless Execute.Dispatcher
had been explicitly defined. This was to detect cases where the user hadn't
set up Execute correctly, and treat them as errors rather than simply going
ahead with some possibly-unexpected behaviour.
However, since BootstrapperBase sets Execute.Dispatcher automatically, it's
highly unlikely that itwould ever not be set when it needed to be. Exceptions
are design mode and unit tests, both of which want (or can cope with) a
synchronous dispatcher.
Hence the behaviour change. Execute.Dispatcher is a synchronous dispatcher
by default, but is overridden to one that uses Application.Current.Dispatcher
by the bootstrapper if we're in a real application.
It looks like the SynchronizationContext can now change on the same thread
(see http://msdn.microsoft.com/en-us/library/system.windows.basecompatibilitypreferences.reusedispatchersynchronizationcontextinstance%28v=vs.110%29.aspx)
meaning that we can no longer do a reference comparison between SynchronizationContext.Current
and the captured SynchronizationConext to check whether a dispatch is required.
It turns out we shouldn't have been doing this anyway.... So switch to using a Dispatcher,
which does support this stuff.
Additionally, Execute now uses an IDispatcher, which means the implementation can be switched
again in the future. It also makes unit testing easier....
Antony Male