My blog is moving to a new location (merging with my personal project blog) : https://blog.negativeeddy.com

New posts will be going to this new location. I’ve migrated the old posts over there as well.

How to avoid this?

• Stick with Tasks and avoid raw Thread code if you can help it. The threading APIs predate the Task/Async APIs by a decade. Mixing the two can result in bugs like this one unless you are extra careful. Task.Run() is your friend for spawning/managing new Tasks, and it is async lambda friendly.
• Avoid Thread.Abort() like the plague. There are some unusual cases where it makes sense, but the vast majority of the times I see it, I consider it to be a bug. .NET provides a very clean cooperative cancellation mechanism that is simple and thread safe (the CancellationToken) which should be used instead to signal a child task to tear itself down cleanly and predictably.
• More on why async lambdas behave this way from the .NET Framework team

1. Pass the context around all the time
2. Use the already built in IoC container to get the bot state.

• IBotData - this interface is defined, implemented, and registered by the BotBuilder SDK automatically. Whenever you post an Activity to a dialog chain, the SDK loads the IBotData, process the post, then saves the IBotData. So if we put a dependency on this, we will always have the current botstate loaded and available while our dialog or service is running (including user, conversation and private conversation data)
• RootDialog – this is the main dialog, it has a dependency on the IUserData service. This dialog doesn’t know anything about bot state. It just uses the IUserData service to load and save a normal .NET property. The IUserData service will be injected into the constructor parameter automatically.
• UserData – this class is a facade over the bot state. It implements the IUserData service. It depends on the IBotData service, but has no concept of dialogs or dialog contexts. This provides a strongly typed property-like experience for any consumer that want to read/write data that is persisted in bot state
• BotModule – the class that registers RootDialog and UserData with the IoC container

Specifically we need to

1. Create a delegate that will resolve a new RootDialog.
2. Register that delegate for use by the bot (in this scope)
3. Resolve the IPostToBot service.
4. Post the current activity to the IPostToBot service.

“error CS8107: Feature 'async main' is not available in C# 7. Please use language version 7.1 or greater.”

You no longer need the preview version of Visual Studio. Updated directions can be found in the  Xamarin documentation

1. Install Visual Studio 2017 preview 15.3
2. Install the Xamarin Updater extension
3. Update the Xamarin for Visual Studio extension
4. Install on Xamarin Live Player on your phone

Regular async/await

1. Buttons disabled
2. UI freezes for 1 second periodically when BlockingWorkAsync() blocks synchronously on Thread.Sleep
3. Buttons enabled

Shallow coverage with ConfigureAwait(false)

1. Buttons disabled
2. UI freezes once for 1 second during the first DoWorkAsync() call
3. UI unfrozen for subsequent calls to DoWorkAsync()
4. Buttons enabled

Full coverage with ConfigureAwait(false)

1. Buttons disabled
2. UI unfrozen for all calls to DoWorkAsync()
3. Buttons enabled

Going manual without ConfigureAwait(false)

Additional notes

• The sample is available on my github repo. That code uses some extra methods which I’ve removed in the snippets above. Those methods just print some diagnostic info out so that you can look at the debug output and see the context flowing or not existing at all the various points in the app. It also contains a Case 4 which uses Task.Run to invoke the method instead of the Case 3 wrapper. These two cases are very similar but when Task.Run is used, the method gets queued to the thread pool and will start at some later point in time. Case 3 will initiate the asynchronous method immediately.
• I am not advocating never using ConfigAwait(false). I’ve had very good success using it in specific targeted scenarios when we knew where the problem was and where to put ConfigureAwait(false) to resolve that problem. I am suggesting that it’s not a cure all and that blanketed use of ConfigAwait is not a good practice.
• I’m also open to other suggestions. After discussing this with others and looking at a few different options (one of them is in the Github history of case 3), this seems the most reasonable so far.
• This sample is a WPF application because its easiest to visualize for demo purposes, but the concept is applicable to any .NET library with async code whether running on the client, on a server, or in the cloud.

The PowerShell way

get-childitem -Directory -Recurse | where-object {$_.Name -eq 'bin' -or $_.Name -eq 'obj' -or $_.Name -eq 'packages'} | Remove-Item –Force –Recurse

void DoWorkPollingTask()
{
    Task.Run(async () =>
    {
        while (true)
        {
            // do the work in the loop
            string newData = DateTime.Now.ToLongTimeString();

            // update the UI on the UI thread
            Dispatcher.Invoke(() => txtTicks.Text = "TASK - " + newData);

            // don't run again for at least 200 milliseconds
            await Task.Delay(200);
        }
    });
}

DispatcherTimer _timer = new DispatcherTimer();

void DoWorkTimer()
{
    _timer.Interval = TimeSpan.FromMilliseconds(200);
    _timer.Tick += _timer_Tick;
    _timer.IsEnabled = true;
}

void _timer_Tick(object sender, EventArgs e)
{
    // do the work in the loop
    string newData = DateTime.Now.ToLongTimeString();

    // update the UI on the UI thread
    txtTicks.Text = "TIMER - " + newData;
}

private async Task DoWorkAsyncInfiniteLoop()
{
    while (true)
    {
        // do the work in the loop
        string newData = DateTime.Now.ToLongTimeString();

        // update the UI
        txtTicks.Text = "ASYNC LOOP - " + newData;

        // don't run again for at least 200 milliseconds
        await Task.Delay(200);
    }
}

private void bttnStart_Click(object sender, RoutedEventArgs e)
{
    // invoke loop method but DO NOT await it
    DoWorkAsyncInfiniteLoop();
}

• Should I write code this way? As always, it depends. But having one more option doesn't hurt.
• Of course these don’t have to be infinite loops, we could institute some kind of flag or cancellation mechanism, but this way makes for simpler example code and a more interesting blog title!
• Don’t do this if you have a large amount of work to do. This is all happening on the UI thread so each time around the loop, its grabbing that UI thread and using it (which means the UI is not responsive at that time). If the work is significant, then Task.Run is a probably better option to offload the work onto another thread.
• The simple example here doesn't prevent reentrancy. If something calls the method again, you will get a second  loop running in addition to the original loop. It won't be parallel (still only on the UI thread) but will be interleaved with the rest of the UI thread work.

1. When you use the async keyword, your method becomes asynchronous because it gets broken into Tasks based on the await keywords in use.
2. Your async method will return before it completes. Yes, that's the whole point and is obvious to some people, but here it is shown explicitly because in the final example above, our method isn’t doing any real work except creating the Task chain and then returning.
3. The code before the first await always runs synchronously. There is no Task management going on until you hit the first await. So if you have a 10 second operation before the first await, the method will take 10 seconds and then hook up the task chain and return.
4. This is why your callstack looks different when debugging. The “after” code is not being called from DoWorkWithoutAwait(). It is being called directly from the .NET Task infrastructure as a continuation of the previous task.

Taking that a bit further

• PPT showing code transitions
• Source code

You can get the latest version at their home page https://openlivewriter.org/ and if you want to get involved with helping continue to make it better check out the source at https://github.com/OpenLiveWriter.

Looking through my email archives, I made an internal suggestion to open source this back in April of 2014. I have no idea if that started the actual process because I wasn't involved, but if it did,  your welcome