I am attempting to open a WPF Window that contains a WebView2 control so I can add OpenID Connect authentication to an existing C++ CLI application.
We are using https://github.com/IdentityModel/IdentityModel.OidcClient.Samples/tree/main/WpfWebView2/WpfWebView2 as the basis of our code.
If you are not familiar with this sample, the idea behind it is there a “custom” class that represents the “browser”. This class is responsible for instantiating the WPF Window, adding a WebView2 control as its content, navigating to the OAuth site, and returning the auth results to the caller. All of this happens when its InvokeAsync() method is called.
What calls this async method is the OidcClient class from the IdentityModel.OidcClient library. The OidcClient class takes in a settings class, one of which is the class that implements its IBrowser interface. You kick off this authentication logic by calling OidcClient.LoginAsync from your application. In my case, this is the C++ code.
When I call LoginAsync() from my C++ code, the app blocks and the window does not open. I am pretty sure that this is a UI thread issue but for the life of me I cannot figure it out.
I have attempt a number of approaches including trying to wrap calls in Application.Current.Dispatcher.Invoke() and Application.Current.Dispatcher.BeginInvoke(). I have tried detecting if I was on the UI thread so I can create a DispatcherSynchronizationContext.
I suspect the issue is the async/await call from C++ that starts with non-UI work and at some point needs to do the UI work. From C++, I can easily create instances of WPF Window (via gcnew) and then call Show() or ShowDialog() but this multiple layer async/await design is causing problems.
I am using LoginAsync().Wait() from the C++ side so it is very possible that this is simply a matter of not calling the async method from C++ correctly. I am not even sure where else to look or what additional knowledge I need to debug this specific set up.
3
The call to .Wait() pretty sure causes deadlock.
If you don’t need a result from LoginAsync immediately, register continuation using .ContinueWith(...) instead.
If you need a result from LoginAsync synchronically then start a new DispatcherFrame in UI thread. C# code would look like this:
// Assuming that the 't' is a Task<...>.
var t = LoginAsync();
var frame = new DispatcherFrame();
t.ContinueWith((_) => { frame.Continue = false; }, TaskContinuationOptions.ExecuteSynchronously);
// Block current thread until LoginAsync is completed, while performing all UI stuff.
// (Make sure you call this in UI thread)
Dispatcher.PushFrame(frame);
// Since 't' is already completed, this call won't block the thread.
var loginResult = t.Result;
2
Since my original question was in regards to calling the C# async method from C++/CLI without blocking the entire application, I will post my ported code here from the answer Sinus32 provided. (He will be given credit for the answering the post.)
That being said, I still am not 100% sure why DispatcherFrame is the solution as opposed to other dispatchers like Application.Current.Dispatcher…
// C# class that gathers OAuth settings from the app config file and ultimately
// calls into IdentityModel.OidcClient to do the authentication
MyCompany::Client::Authentication::IAuthenticationService^ authService =
gcnew MyCompany::Client::Authentication::OidcAuthenticationService();
// PerformLoginAsync calls OidcClient.LoginAsync() which calls IBrowser.InvokeAsync()
// which is responsible for creating the WPF Window with the embedded browser
//
// It is in here where I added code to switch to the WPF UI thread so
// the controls can be created.
auto loginTask = authService->PerformLoginAsync();
auto frame = gcnew System::Windows::Threading::DispatcherFrame();
// Since the callback needs to update the Continue method of DispatcherFrame and the
// callback is of Action<Task>, you need to treat frame variable as a "captured variable"
// and explicitly pass it in. It is my understanding that the dotnet compliler does this
// via a Field but I choose to do so via the ctor
auto helper = gcnew MyCompany::Client::Authentication::DispatcherFrameHelper(frame);
// This is needed since, as Ben Voight mentions, C++/CLI does not support lambdas.
auto callback = gcnew System::Action<System::Threading::Tasks::Task^>(helper, &MyCompany::Client::Authentication::DispatcherFrameHelper::SetDispatcherFrameToContinue);
loginTask->ContinueWith(callback, System::Threading::Tasks::TaskContinuationOptions::ExecuteSynchronously);
System::Windows::Threading::Dispatcher::PushFrame(frame);
auto result = loginTask->Result;
1