I’m trying async-await programming with entity-framework 6 (code first) + WPF and I can’t see why the UI still freezes after I made the code asynchronous.
Here is what I’m doing from the very first line:
first there is an event handler responding to a click button:
private async void LoginButton_Click(object sender, RoutedEventArgs e) {
if (await this._service.Authenticate(username.Text, password.Password) != null)
this.Close();
}
Then I have the Authenticate method in my service layer:
public async Task<User> Authenticate(string username, string password) {
CurrentUser = await this._context.GetUserAsync(username.ToLower().Trim(), password.EncryptPassword());
return CurrentUser;
}
and at the end is the EF code in the context:
public async Task<User> GetUserAsync(string username, string password) {
return await this.People.AsNoTracking().OfType<User>().FirstOrDefaultAsync(u => u.Username == username && u.Password == password);
}
Update: After some tracing the cause of UI freezing turned out to be the initialization process. UI thread blocks until the EF context is initialized and once that is done the actual querying/saving process is performed asynchronously.
Update Debug output after the call on Task.Yield() at the beginning of the click handler:
53:36:378 Calling Task.Yield
53:36:399 Called Task.Yield
53:36:400 awaiting for AuthenticateAsync
53:36:403 awaiting for GetUserAsync
'MyApp.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_32\System.Transactions\v4.0_4.0.0.0__b77a5c561934e089\System.Transactions.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'MyApp.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Numerics\v4.0_4.0.0.0__b77a5c561934e089\System.Numerics.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'MyApp.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_32\System.Data.OracleClient\v4.0_4.0.0.0__b77a5c561934e089\System.Data.OracleClient.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'MyApp.vshost.exe' (Managed (v4.0.30319)): Loaded 'D:\SkyDrive\Works\MyApp\MyApp.UI.WPF.Shell\bin\Debug\EntityFramework.SqlServer.dll'
'MyApp.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_32\System.EnterpriseServices\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.EnterpriseServices.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'MyApp.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_32\System.EnterpriseServices\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.EnterpriseServices.Wrapper.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'MyApp.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Runtime.Serialization\v4.0_4.0.0.0__b77a5c561934e089\System.Runtime.Serialization.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'MyApp.vshost.exe' (Managed (v4.0.30319)): Loaded 'EntityFrameworkDynamicProxies-MyApp.Model.Domain.People'
'MyApp.vshost.exe' (Managed (v4.0.30319)): Loaded 'EntityFrameworkDynamicProxies-MyApp.Model.Domain.Security'
53:39:965 Out of GetUserAsync
53:39:968 out of AuthenticateAsync
The thread '<No Name>' (0x1e98) has exited with code 0 (0x0).
The thread '<No Name>' (0x17d4) has exited with code 0 (0x0).
The thread '<No Name>' (0x175c) has exited with code 0 (0x0).
The thread '<No Name>' (0x220) has exited with code 0 (0x0).
The thread '<No Name>' (0x1dc8) has exited with code 0 (0x0).
The thread '<No Name>' (0x1af8) has exited with code 0 (0x0).
Methods marked ‘async’ are still synchronous up until the point when the first ‘await’ happens. Because of that, if any of what happens in that initial code takes too long (200ms or more I think is the guideline for WinRT, which seems reasonable), then you may want to force the code to return faster by inserting an await earlier.
For instance, in your LoginButton_Click, you can insert a first line of ‘await Task.Yield()’ which will allow the call to return back to the UI thread faster.
Now, with that change alone, the methods will all still run on the UI thread due to the async/await behavior. I still like making that change first because in many cases it’s what the user actually expects is happening (the ‘async’ modifier being kind of confusing in that regard), and it’s something you can do at the start of a handler without having to mess with things further down the stack.
The next step we can do if the above is insufficient (like the context initialization is taking too long, still happens on the UI thread, and still freezes the UI, just at a slightly different point in time) is taking those parts that don’t need to happen on the UI thread and let await know that they can be processed on any thread, not just the UI thread. This is generally a good practice anyway for responsiveness, even in scenarios where the code currently runs ‘fast enough’ to not be a noticeable problem.
For that, we use add ConfigureAwait(false) to the Task.
Once both of those changes are in, you’ll both 1) be returning control back to the caller as quickly as you can (doing the least amount of code synchronous to the event handler) and 2) be doing work that doesn’t need to be on the UI thread on other threads, which should hopefully mean your UI doesn’t ‘freeze’ any more.
If it still freezes after those changes, you might just need to run it under a debugger, and when it freezes, break to see what the stack of the UI thread is to find the offending code. 🙂
Good luck!