Here’s what it looks like:

public static async AsyncEnumerable<int> GetValuesAsync()
{
    for (int i = 0; i < 5; i++)
    {
        await Task.Delay(200);
        await Task.FromResult(i).YieldReturn();
    }

    return default(int); // dummy value
}

What are async iterators?

In .NET we use the IEnumerable<T> and IEnumerator<T> interfaces to create forward-only iterators. The enumerator interface contains a bool MoveNext() method, that when called, advances the iterator to the next item.

Async iterators replace this method with Task<bool> MoveNext(), so that each step can be performed asynchronously. This is useful when the next item should be retrieved asynchronously – mainly because it incurs IO, such as when iterating over Entity Framework entities (materialized from a DbDataReader) and Service Fabric Reliable Collections (which may require disk IO if the items are not in memory). Both of these frameworks expose their own IAsyncEnumerable<T> and IAsyncEnumerator<T>, which work as I just described.

The RX project has yet another implementation for async enumerable, which also provides a full LINQ implementation, so you can use operators such as Where and Select.

Language support

Unfortunately, C# is lagging a bit behind. While it does support creating iterators using yield return and async methods using async and await, currently there’s no way to combine the two. Or is there?

Roslyn 2.0 introduced a very nifty feature – “arbitrary async returns”. This was added mainly to address some allocation optimizations when dealing with Tasks (which are reference types) by providing an awaitable value type that defers the creation of the task until absolutely necessary, called ValueTask. But the compiler feature is much more flexible than that – it enables us to create custom “async method builder” classes that allow returning any type from an async method.

I realized this feature could be somewhat abused to create async iterators, as seen in the above example.

How does it work?

There are two main pieces:

• A YieldReturnAwaitable which the extension method YieldReturn() returns. This awaitable/awaiter just wraps the task’s awaiter, except for the IsCompleted property, which always returns false.
• AsyncEnumerableTaskMethodBuilder<T> which allows the compiler to create the async state machine. It works differently from the task method builder, because when returning an enumerable, it can be invoked multiple times by calling GetEnumerator(). Also, the async state machine’s MoveNext() is not invoked automatically, but rather by the enumerator’s MoveNext().
  • The state machine is started by calling AsyncEnumerator<T>.MoveNext(). A TaskCompletionSource<bool> is created to hold the return value of MoveNext().
  • Each time there’s an await in the method, the AwaitOnCompleted gets called (unless it completes synchronously). That’s why YieldReturnAwaiter.IsCompleted always returns false - otherwise the state machine would skip AwaitOnCompleted for completed tasks, and we’d never get a chance to intercept the yield. If it’s our special YieldReturnAwaiter, we stop executing and set the MoveNext() task result to true. We also fetch the value using the awaiter’s GetResult() method. Otherwise (as in the Task.Delay() in the example), we just hook up the continuation and let it continue until hitting the next “yield return”.

There’s a small “type safety” issue – the compiler won’t stop us from using YieldReturn() on any type in the method. But of course we only take values from yields that match the method’s return type.

Lastly, this is just a prototype. I’ll have to review it more thoroughly to make sure it’s thread safe. I’m also not sure if ExecutionContext capturing was done correctly.

You can see the full implementation in SharpLab.

So for the time being, I’ve updated the RoslynPad sample to use the myget Roslyn-nightly feed, which contains the EditorFeatures assemblies, and falling back to Reflection again to use the internal APIs.

Download

In addition, this version has a few neat new features:

• Code completion and signature help provide an experience much more similar to VS:

• A new DumpToPropertyGrid extension method:

• Improved performance, formatting and new glyph icons (courtesy of the now XAML-friendly VS Image Library)

System.Exception: Crash! Boom! Bang!
at AsyncFriendlyStackTrace.Test.Example1.<C>d__3.MoveNext() in C:\Source\Repos\AsyncFriendlyStackTrace\src\AsyncFriendlyStackTrace.Test\Example1.cs:line 26
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at AsyncFriendlyStackTrace.Test.Example1.<B>d__2.MoveNext() in C:\Source\Repos\AsyncFriendlyStackTrace\src\AsyncFriendlyStackTrace.Test\Example1.cs:line 20
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at AsyncFriendlyStackTrace.Test.Example1.<A>d__1.MoveNext() in C:\Source\Repos\AsyncFriendlyStackTrace\src\AsyncFriendlyStackTrace.Test\Example1.cs:line 15
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at AsyncFriendlyStackTrace.Test.Example1.<Run>d__0.MoveNext() in C:\Source\Repos\AsyncFriendlyStackTrace\src\AsyncFriendlyStackTrace.Test\Example1.cs:line 10
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at AsyncFriendlyStackTrace.Test.Program.Run[TExample](TextWriter writer) in C:\Source\Repos\AsyncFriendlyStackTrace\src\AsyncFriendlyStackTrace.Test\Program.cs:line 45

I’ve been using Service Fabric lately, and async is used everywhere. It made the logs hard to read and larger than they should be.

So (after some deliberation with a Microsoft diagnostics engineer) I decided to create a library that formats stack traces much more concisely:

AsyncFriendlyStackTrace

Usage is a single extension method call:

exception.ToAsyncString()

Here’s what the above stack trace would look like:

System.Exception: Crash! Boom! Bang!
at async AsyncFriendlyStackTrace.Test.Example1.C(?) in C:\Source\Repos\AsyncFriendlyStackTrace\src\AsyncFriendlyStackTrace.Test\Example1.cs:line 26
at async AsyncFriendlyStackTrace.Test.Example1.B(?) in C:\Source\Repos\AsyncFriendlyStackTrace\src\AsyncFriendlyStackTrace.Test\Example1.cs:line 20
at async AsyncFriendlyStackTrace.Test.Example1.A(?) in C:\Source\Repos\AsyncFriendlyStackTrace\src\AsyncFriendlyStackTrace.Test\Example1.cs:line 15
at async AsyncFriendlyStackTrace.Test.Example1.Run(?) in C:\Source\Repos\AsyncFriendlyStackTrace\src\AsyncFriendlyStackTrace.Test\Example1.cs:line 10
at AsyncFriendlyStackTrace.Test.Program.Run[TExample](TextWriter writer) in C:\Source\Repos\AsyncFriendlyStackTrace\src\AsyncFriendlyStackTrace.Test\Program.cs:line 45

Try the library, review the motivating examples in the repo, and let me know what you think. If this gets enough traction perhaps Microsoft could be convinced to add an extensibility point that would allow changing the default stack trace format.

Update: Since .NET 6, the runtime formats async stack traces concisely out of the box, so this library is no longer needed and its repo has been archived.

With Service Fabric SDK v2 this became much simpler. Check out this SO answer of mine for details.

Service Fabric’s default communication stack for Reliable Services provides a simple way to enable communications without worrying about protocols, discovery, and much more as we shall see. To use the stack, we need to create a ServiceRemotingListener, which implements ICommunicationListener, as well as create a service interface:

interface IMyService : IService
{
    Task<MyData> DoIt();
}

class MyService : StatelessService, IMyService
{
    protected override IEnumerable CreateServiceInstanceListeners()
    {
        return new[] { new ServiceInstanceListener(parameters => new ServiceRemotingListener(parameters, this)) };
    }

    public Task<MyData> DoIt()
    {
        return Task.FromResult(new MyData());
    }
}

Then, to use the service, we can create a proxy using ServiceProxy:

var myService = ServiceProxy.Create<IMyService>();
await myService.DoIt();

However, what the stack doesn’t trivially provide are hooks for adding headers and instrumentation for the service operations. Headers are essential in modern SO architectures. They can allow ambient information such as identity to pass along messages. Instrumentation allows you to add code when a service operation starts and ends. This could be used for logging, error handling, authorization and more. In this post I will share a solution for adding both of these.

Get the code

This sample is no longer relevant with SDK v2 and has been removed

https://github.com/aelij/samples-servicefabric-instrumentation

How it works

In the latest preview, two additions were made to the service API that enable this – both ServiceRemotingListener and ServiceProxy now accept a factory that allows us to construct the “inner” communication listener and client. What does this mean? Both the listener and the proxy are higher level abstractions, and they use inner classes to provide the actual communication layer. By default, Service Fabric uses WCF. All of this implementation is internal, so in the sample code you’ll see a replica of that internal code with the added hooks.

The heart of the solution relies on the WcfRemotingService class, which is the implementation of the WCF service. This class receives generic messages, in the form of a byte array, later to be decoded and dispatched into our implementation (e.g. the MyService class above). So, essentially, we can add any code before and after the execution of the method.

Service Fabric uses the class ServiceRemotingMessageHeaders to send metadata about which interface and method were called. This data is encoded into integer hashes of the names. The sample code also shows how to decode this data for logging purposes. This could be very useful for other uses, such as extracting attributes from the methods, and applying policy according to them. In addition, we can add our own headers. In the sample, I’ve added the ClaimsIdentity of the client to the headers. I’m using a neat .NET 4.6 class called AsyncLocal<T> to allow the context to flow between awaits (note that 4.6 is not installed on Service Fabric clusters by default, and requires additional setup).

The other part of the solution is the client side, in the WcfServiceRemotingClient class. That is where we add the headers before sending requests to the server.

How to use it

In the sample code above, simply replace new ServiceRemotingListener with ServiceRemotingListenerEx.Create and ServiceProxy with ServiceProxyEx. This will enable the custom listener and client.

Note the edges are still rough (think version 0.1), and it’s still missing a lot of features the original tool has. I welcome criticism and ideas; please use GitHub Issues for those.

Screenshots

A while back I created a small sample that exposed the Roslyn code completion (a.k.a. Intellisense) APIs via Reflection. This was during the CTP days of Roslyn, and I hoped these APIs would become public when Roslyn hits RTM.

Much has changed in Roslyn during these past two years, and I wanted to update the sample. The completion APIs are still internal, but fortunately now Roslyn is an open-source project. I compiled my own version, and exposed both ICompletionService and ISignatureHelpProvider. The latter allows me to display method signatures and overloads. I’ve created a new assembly, Microsoft.CodeAnalysis.EditorFeatures.Minimal in lieu of Microsoft.CodeAnalysis.EditorFeatures that does not depend on Visual Studio’s (proprietary) assemblies.

Download the sources (with the modified Roslyn binaries) from

https://github.com/aelij/roslynpad

This can be pretty important, especially when awaiting tasks in code that was initialized from a UI thread, which has a Synchronization Context. Poorly written code can easily result in a deadlock, not to mention a serious perf hit. For example:

class MyWindow : Window
{
    private void MyButton_Click(object sender, EventArgs e)
    {
        DoSomething().Wait();
    }

    private async Task DoSomething()
    {
        await Task.Run(() => { });
    }
}

This is obviously bad, calling Wait() on the UI thread. But it’s easy to imagine more subtle ways this could happen inside library code. That’s why the best practice is to always use ConfigureAwait(continueOnCapturedContext: false) in library code. I really wish they’d split that into two separate methods. I also wish they’d made the default to be false.

I’ve recently come to the conclusion that it’s best to always specify ConfigureAwait everywhere lest you forget. So I wrote up a small ReSharper plugin (my first) that checks for it and also provides a quick-fix (ReSharper provides an awesome extensibility model):

Download it from the ReSharper extensions gallery: http://resharper-plugins.jetbrains.com/packages/ConfigureAwaitChecker

ReSharper 9 (different package): https://resharper-plugins.jetbrains.com/packages/ConfigureAwaitChecker.v9

• They don’t allow you to resize, minimize or do anything with the containing window
• As a consequence of the above, when you use WIN+D to show the desktop, then open another window, they suddenly pop back up from nowhere (along with the containing window, of course)
• You can’t have dialogs that are context-specific (e.g. a certain tab)
• They misbehave if you don’t set their parent explicitly (sometimes hiding behind other windows, accessible only via crazy ALT-tabbing)
• They make that annoying ‘ding’ sound when you click the containing window

There’s a better way

InlineModalDialog, available in the latest version of WPF Contrib, works a bit differently:

• It creates an inline dialog that is contained within the window
• It constrains the input (keyboard, mouse & touch) to the dialog; WPF can easily do that with its sophisticated keyboard navigation options and hit-testing invisibility
• It uses a Dispatcher frame to block the caller of the Show() method, just like a regular dialog does
• You can layer dialogs on top of each other
• You can define multiple scopes in which the dialogs appear

How to use

Add the decorator below the element to be used as the container. Set the Target property to the container.

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:av="http://schemas.codeplex.com/wpfcontrib/xaml/presentation"
             Name="RootContainer">
    <av:InlineModalDecorator Target="{x:Reference RootContainer}">

    </av:InlineModalDecorator>
</UserControl>

Create a dialog and show it:

var dialog = new InlineModalDialog
{
    Owner = this,
    Content = new MyDialogViewModel(),
};
dialog.Show();

The Owner can be any element contained within the Target specified in the decorator (or the target itself).

You may also use the new ShowInline() overloads in TaskDialog.

##

Limitations

• In the current implementation, you can’t move or resize the dialogs (but they can be resized with the container using stretching and margins). This can be easily mitigated, and I may address it in a future release.
• The developer needs to be more aware of the dialogs’ state, especially when these are dialogs that are shown when closing a window. For example, what happens if, while editing a document, the user has opened a settings dialog and clicks the window’s close button? Should you ask whether to save the settings? Save the document? Ignore/disable it? It’s up to you to decide what’s the better UX.

So I set out to look for a solution. It seems that normally Windows does not provide this information in WM_KEY{UP, DOWN} messages. You had to register your process to receive WM_INPUT messages, which contain information about which HID (Human Interface Device) was used. These messages are sent in addition to the standard input messages (keyboard, mouse, touch).

I found a good project in Code Project that encapsulated most of the functionality I needed.

https://github.com/aelij/RawInputProcessor

This solution contains a unified API for both WPF and Windows Forms. It also allows marking events as handled. It uses the PeekMessage function to remove the WM_KEY{UP, DOWN} messages, so WPF’s InputManager never receives them. I’ve also cleaned up the code and fixed a few bugs and a few possible leaks.