Async/Await Feature for WebMap Blazor

Blazor Async/Await Service and Graph approach

In WebMap Blazor, we need the MessageBox Show and the InputBoxShow to be awaited. For this reason, it is necessary to have an asynchronous architecture for methods that call the MessageBox Show or the InputBox Show. For this documentation purposes we are calling every "awaitable" call, like that, an AwaitableCall.

But, what happens when a method that calls an AwaitableCall, is called inside another method? And then another method called those methods.

We can have a chain of async and await calls. But how can we determine in the migration where to put an await and where to put an async?

For this reason, we decided to build a Graph, to have all the dependencies between client code methods and calls. And, using a service, we are going to save in a Hash set all the async methods. By doing this, we can ask in the transformation rules if a method is registered as an async method.

A graph looking like this:

Graph Example

As you can see the MyMethod should be async. Why? Because if you follow the route of calls and dependencies, the last call is to an AwaitableCall.

The Blazor Async Method Service

This is the service that saves the dependencies graph(This graph is not saving or marking the async methods, just saving the call dependencies between methods), and then HashSet that has all the methods that should be async.

Where is the graph builded?. Well, let's take a look at the AsyncAwaitsCollector.

Here in the Collect method, the searcher will execute in every CSMethod node to build the dependencies.

Here we don’t need to register as method roots the methods coming from System or UpgradeHelpers.

Then when the Graph is built, we can now register all the async methods. Let’s jump to the BlazorAsyncAwaitsCollectorTask.

Here, the MarkAsyncMethods is called to go through the graph and register the methods that need to be async.

Supported Scenarios for MessageBox

Using this feature we are supporting the next scenarios in migration:

MessageBox call needs to wait a response to continue execution

var res = MessageBox.Show(...)
...

var res = DialogResult.None
res = MessageBox.Show(...)
...

if(MessageBox.Show(...) == DialogResult.Yes)
...

if(MessageBox.Show(...) != DialogResult.Yes)

This will be converted to

var res = await MessageBox.Show(...)
...

var res = DialogResult.None
res = await MessageBox.Show(...)
...

if(await MessageBox.Show(...) == DialogResult.Yes)
...

if(await MessageBox.Show(...) != DialogResult.Yes)

MessageBox does not need to wait for a response from the user. This is changed by the ShowNotification mechanism

...
MessageBox.Show("Error validating date")
...

This will be transformed to

...
Application.CurrentApplication.ShowSimpleNotification("Error validating date")
...

Every method and call that has a MessageBox call and is not a simple notification, is going to have an async modifier.

For the MessageBox waiting a response

public void ShowMessage(string message)
{
	...
	var res = MessageBox.Show(...);
	...
}

This will be transformed to

public async void ShowMessage(string message)
{
	...
	var res = await Message.Show(...);
	...
}

For a simple MessageBox

public void ShowMessage(string message)
{
	...
	MessageBox.Show(...);
}

This will be transformed to

public void ShowMessage(string message)
{
	...
	Application.CurrentAplication.ShowSimpleNotification(...);
	...
}

Not Supported Scenarios

If you have a scenario where an async method is being called in the FormLoad, the constructor or the DefInstance(from VBUC Migration), there will be a lot of issues. Please refer to the Alternatives to Async Properties in C# section

This scenario is not supported. The CreateInstance is async by the Async/Await feature