0

I have problem with failing RaisePropertyChanged in my application. It is called after receiving message from another class. This message is sent after await calling.

var storedData = await localFolder.GetFileContentAsync("data.json").ConfigureAwait(false);
if (!string.IsNullOrEmpty(storedData))
{
    snags = JsonConvert.DeserializeObject<Data>(storedData);
    messenger.Send(new ChangeDataCountMessage());
}

Failing RaisePropertyChanged

public Data DataProperty
{
    get { return dataProperty; }
    set
    {
        dataProperty = value;
        RaisePropertyChanged();
    }
}

This call of RaisePropertyChanged throws exception 

An exception of type 'System.Runtime.InteropServices.COMException' occurred in System.dll but was not handled in user code

Additional information: The application called an interface that was marshalled for a different thread. (Exception from HRESULT: 0x8001010E (RPC_E_WRONG_THREAD))

Additional info :

  • I use portable GalaSoft.MvvmLight (Messenger, RaisePropertyChanged etc.) v. 4.4

  • all this happens in PortableClassLibrary

  • it is not happening all the time

  • I don't send any data from another thread

Could you help me please?

y0j0
  • 3,369
  • 5
  • 31
  • 52

1 Answers1

2

Change ConfigureAwait to true, or remove the ConfigureAwait. you want to continue processing on the GUI thread. You can do ConfigureAwait(false) if you are sure that whatever comes next is not required to be on the GUI thread. There are some good explanations available on the internet from Steven Cleary.

http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html

Best practice to call ConfigureAwait for all server-side code

The reason why it is not happening all the time is that sometimes it is the GUI thread that is going to continue, but if you do configureawait(true) you are really forcing it to be the GUI thread to continue. If you drop the configureawait completely, that is the same as configureawait(true) because it is the default.

Community
  • 1
  • 1
Philip Stuyck
  • 7,344
  • 3
  • 28
  • 39
  • Thanks a lot. I was confused because everywhere I read was that best practice is ConfigureAwait(false). But true is that I didn't understand why :) – y0j0 Mar 18 '15 at 09:50