I have just realized that several of my view-models violate a key rule of the function BindingOperations.EnableCollectionSynchronization The docs state that it must be called from the UI thread. I know of at least 2 view-models that break this rule
I know I have to fix this but I am very close to a release and am concerned about any major changes right now. This code has been running this for a while now without any discernible issue; No warnings from WPF about calling the function or updating a collection from a non-UI thread; No apparent synchronization issues.
Does anyone know what the exact consequences of this bad practice are? I just want to gauge my risk before I hold the presses to make changes that are going to require a lot more testing. I've tried stepping into the code but I get lost in views and ShadowCopy code.
Each thread creates its own copy of ViewManager. Therefore, calling BindingOperations.EnableCollectionSynchronization from another thread will not result in an exception being thrown. The result will be the registration of the collection in the ViewManager instance associated with the current thread.
The exception may occur later. If you update such a collection from a background thread and this collection is bound to WPF elements, then when checking the ViewManager of the main thread, this collection will not be found in it, which may result in an exception being thrown.
Since you have not encountered such an exception, it is quite possible that such a situation does not occur in your application. This can only be answered with certainty by conducting a full analysis of the code.