The current implementation of the PropertyChangedBase.NotifyPropertyChanged always dispatches events handlers on the UI thread. Such behavior is pretty much extreme, and not intuitive.
I am aware of the fact that some pieces of code could rely on such a feature (see [this issue](http://caliburnmicro.codeplex.com/workitem/286) about ActionMessage), but in such cases the handlers should be responsible to ensure thread affinity, not the caller.
The current behavior can lead to unexpected and hard to track UI slow-downs, expecially in case the new C# async feature is used.
I reamember that early versions of the Xaml engine (CTP or alike) did not ensure thread affinity for property change notification, is this the reason for such a choice?
Comments: Fixed
I am aware of the fact that some pieces of code could rely on such a feature (see [this issue](http://caliburnmicro.codeplex.com/workitem/286) about ActionMessage), but in such cases the handlers should be responsible to ensure thread affinity, not the caller.
The current behavior can lead to unexpected and hard to track UI slow-downs, expecially in case the new C# async feature is used.
I reamember that early versions of the Xaml engine (CTP or alike) did not ensure thread affinity for property change notification, is this the reason for such a choice?
Comments: Fixed