Using async/await with IAsyncResult pattern

2016-02-122016-02-22 TPodolakasync-await, IAsyncResult

Even though in my current project we use .NET 4.5 we still have lots of references to internal libraries targeting .NET 4.0. Usually it is not a problem, however some of these libraries follow Asynchronous Programming Model pattern. This approach makes the code quite ugly because we end up with lots of nested callbacks.

// rest of the code omitted for brevity
private static void GetHostEntryIAsyncResultPattern()
{
    DnsService dnsService = new DnsService();
    dnsService.BeginGetHostEntry(GoogleHost, googleAsyncResult =>
    {
        var googleHostResult = dnsService.EndGetHostEntry(googleAsyncResult);
        Console.WriteLine($"Result from IAsyncResultPattern: {GoogleHost} - {FormatHostEntry(googleHostResult)}");
        dnsService.BeginGetHostEntry(YahooHost, yahooAsyncResult =>
        {
            var yahooHostResult = dnsService.EndGetHostEntry(yahooAsyncResult);
            Console.WriteLine($"Result from IAsyncResultPattern: {YahooHost} - {FormatHostEntry(yahooHostResult)}");
        }, null);
    }, null);
}
// rest of the code omitted for brevity

// rest of the code omitted for brevity

private static void GetHostEntryIAsyncResultPattern()

{

DnsService dnsService = new DnsService();

dnsService.BeginGetHostEntry(GoogleHost, googleAsyncResult =>

{

var googleHostResult = dnsService.EndGetHostEntry(googleAsyncResult);

Console.WriteLine($"Result from IAsyncResultPattern: {GoogleHost} - {FormatHostEntry(googleHostResult)}");

dnsService.BeginGetHostEntry(YahooHost, yahooAsyncResult =>

{

var yahooHostResult = dnsService.EndGetHostEntry(yahooAsyncResult);

Console.WriteLine($"Result from IAsyncResultPattern: {YahooHost} - {FormatHostEntry(yahooHostResult)}");

}, null);

}

// rest of the code omitted for brevity

Fortunately thanks to

Task.Factory.FromAsync

1	Task.Factory.FromAsync

method it is possible to quite easily make Begin/End methods work with async/await pattern. All you have to do is to pass Begin/End methods as an arguments to Task.Factory.FromAsync and you are good to go. The original code after refactoring looks like that

// rest of the code omitted for brevity
var dnsService = new DnsService();
var googleHostResult = await Task.Factory.FromAsync((callback, stateObject) => dnsService.BeginGetHostEntry(GoogleHost, callback, stateObject), dnsService.EndGetHostEntry, null);
Console.WriteLine($"Result from async/await: {GoogleHost} - {FormatHostEntry(googleHostResult)}");

var yahooHostResult = await Task.Factory.FromAsync((callback, stateObject) => dnsService.BeginGetHostEntry(YahooHost, callback, stateObject), dnsService.EndGetHostEntry, null);
Console.WriteLine($"Result from async/await: {YahooHost} - {FormatHostEntry(yahooHostResult)}");
// rest of the code omitted for brevity

// rest of the code omitted for brevity

var dnsService = new DnsService();

var googleHostResult = await Task.Factory.FromAsync((callback, stateObject) => dnsService.BeginGetHostEntry(GoogleHost, callback, stateObject), dnsService.EndGetHostEntry, null);

Console.WriteLine($"Result from async/await: {GoogleHost} - {FormatHostEntry(googleHostResult)}");

var yahooHostResult = await Task.Factory.FromAsync((callback, stateObject) => dnsService.BeginGetHostEntry(YahooHost, callback, stateObject), dnsService.EndGetHostEntry, null);

Console.WriteLine($"Result from async/await: {YahooHost} - {FormatHostEntry(yahooHostResult)}");

// rest of the code omitted for brevity

I think everyone will agree with me that refactored version is much better than original one.
Source code for this post can be found here

EntityFramework – SQLException during database migration

2016-02-072016-02-08 TPodolakEF, Entity Framework, Migration

Recently I’ve been doing some small refactoring of my pet project. Nothing too fancy – just namespace adjustment, variables and class renaming etc. However it turned out that even these minor changes can in fact be major ones. All of the sudden most of my integration tests started failing due to SQLException.

I am using Code First approach so I didn’t take me too much time to realize that for some reasons EntityFramework wanted to create already existing tables. I started looking into the way EF keeps track of the changes in the model and it turned out that it creates special table called

__MigratoinHistory

1	__MigratoinHistory

One of the most important columns in there is column called ContextKey, which identifies the class which describes migration policy. In my case this class originally looked that way

namespace EFAutoupgradeException.Data
{
    public class AutoupgradeExceptionMigrationConfiguration : DbMigrationsConfiguration<AutoupgradeExceptionDbContext>
    {
        public AutoupgradeExceptionMigrationConfiguration()
        {
            this.AutomaticMigrationsEnabled = true;
            this.AutomaticMigrationDataLossAllowed = true;
        }
    }
}

namespace EFAutoupgradeException.Data

{

public class AutoupgradeExceptionMigrationConfiguration : DbMigrationsConfiguration<AutoupgradeExceptionDbContext>

{

public AutoupgradeExceptionMigrationConfiguration()

{

this.AutomaticMigrationsEnabled = true;

this.AutomaticMigrationDataLossAllowed = true;

}

In that case value of the ContextKey column matches the full name of the class

EFAutoupgradeException.Data.AutoupgradeExceptionMigrationConfiguration

1	EFAutoupgradeException.Data.AutoupgradeExceptionMigrationConfiguration

The class after refactoring was slightly changed and now it looks that way

namespace EFAutoupgradeExceptions.Data
{
    public class AutoupgradeExceptionMigrationConfiguration : DbMigrationsConfiguration<AutoupgradeExceptionDbContext>
    {
        public AutoupgradeExceptionMigrationConfiguration()
        {
            this.AutomaticMigrationsEnabled = true;
            this.AutomaticMigrationDataLossAllowed = true;
        }
    }
}

namespace EFAutoupgradeExceptions.Data

{

public class AutoupgradeExceptionMigrationConfiguration : DbMigrationsConfiguration<AutoupgradeExceptionDbContext>

{

public AutoupgradeExceptionMigrationConfiguration()

{

this.AutomaticMigrationsEnabled = true;

this.AutomaticMigrationDataLossAllowed = true;

}

It is easy to overlook the change but now, full name of the class is

EFAutoupgradeExceptions.Data.AutoupgradeExceptionMigrationConfiguration

1	EFAutoupgradeExceptions.Data.AutoupgradeExceptionMigrationConfiguration

so EF loses the information about the migration and tries to migrate once again from the scratch. Fortunately there is an easy fix for that which doesn’t require dropping the database. All you have to do is to write simple update statement which set the proper ContextKey value.

USE EFAutoupgradeException
UPDATE [__MigrationHistory]
SET
[ContextKey] = 'EFAutoupgradeExceptions.Data.AutoupgradeExceptionMigrationConfiguration'
WHERE [ContextKey] LIKE '%AutoupgradeExceptionMigrationConfiguration'

USE EFAutoupgradeException

UPDATE [__MigrationHistory]

SET

[ContextKey] = 'EFAutoupgradeExceptions.Data.AutoupgradeExceptionMigrationConfiguration'

WHERE [ContextKey] LIKE '%AutoupgradeExceptionMigrationConfiguration'

Source code for this post can be found here

Abusing collection initializers

2016-02-012016-02-01 TPodolak.NET, .NET 4.0

Most of .NET developers are familiar with collection initializers syntax. Long story short, this language feature allows you to replace this ugly syntax

var numbers = new List<int>();
numbers.Add(1);
numbers.Add(2);
numbers.Add(3);
numbers.Add(4);

var numbers = new List<int>();

numbers.Add(1);

numbers.Add(2);

numbers.Add(3);

numbers.Add(4);

with much shorter and cleaner one

var numbers = new List<int> { 1, 2, 3, 4 };

1	var numbers = new List<int> { 1, 2, 3, 4 };

The more interesting thing is the fact that you can leverage this syntax not only for build-in collections but also for your custom classes. In order to do that your class must implement IEnumerable interface and expose public Add method. Let’s assume that we have some real case scenario and we have class which looks like that

public class StatusMessages : IEnumerable<StatusMessage>
{
    private List<StatusMessage> messages = new List<StatusMessage>();

    public IEnumerator<StatusMessage> GetEnumerator()
    {
        return this.messages.GetEnumerator();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return this.messages.GetEnumerator();
    }
}

public class StatusMessage
{
    public string Text { get; set; } = string.Empty;
    public string SourceSystem { get; set; } = string.Empty;
    public int StatusCode { get; set; }

    public StatusMessage()
    {
    }

    public StatusMessage(string text)
    {
        this.Text = text;
    }

    public override string ToString()
    {
        return $"Text: {this.Text} StatusCode: {this.StatusCode} SourceSystem: {this.SourceSystem}";
    }
}

public class StatusMessages : IEnumerable<StatusMessage>

{

private List<StatusMessage> messages = new List<StatusMessage>();

public IEnumerator<StatusMessage> GetEnumerator()

{

return this.messages.GetEnumerator();

}

IEnumerator IEnumerable.GetEnumerator()

{

return this.messages.GetEnumerator();

}

public class StatusMessage

{

public string Text { get; set; } = string.Empty;

public string SourceSystem { get; set; } = string.Empty;

public int StatusCode { get; set; }

public StatusMessage()

{

}

public StatusMessage(string text)

{

this.Text = text;

}

public override string ToString()

{

return $"Text: {this.Text} StatusCode: {this.StatusCode} SourceSystem: {this.SourceSystem}";

}

This is a simple wrapper over the List. At this moment we can’t use collection initializer when constructing objects of this classs. However by adding method Add

public class StatusMessages : IEnumerable<StatusMessage>
{
    // rest of the code omitted for brevity
    public void Add(StatusMessage message)
    {
        this.messages.Add(message);
    }
    // rest of the code omitted for brevity
}

public class StatusMessages : IEnumerable<StatusMessage>

{

// rest of the code omitted for brevity

public void Add(StatusMessage message)

{

this.messages.Add(message);

}

// rest of the code omitted for brevity

}

we can create a new instance of that class just like we would do with List

var messagesAddInitializer = new StatusMessages
            {
                new StatusMessage("y"),
                new StatusMessage("x"),
            };

var messagesAddInitializer = new StatusMessages

{

new StatusMessage("y"),

new StatusMessage("x"),

};

What is more, it is possible to have multiple overloads of Add method in our class, so for instance if we add

public class StatusMessages : IEnumerable<StatusMessage>
{
    // rest of the code omitted for brevity
    public void Add(string text)
    {
         this.Add(new StatusMessage(text));
    }
    // rest of the code omitted for brevity
}

public class StatusMessages : IEnumerable<StatusMessage>

{

// rest of the code omitted for brevity

public void Add(string text)

{

this.Add(new StatusMessage(text));

}

// rest of the code omitted for brevity

}

we are able to use this syntax

var messagesAddStringInitializer = new StatusMessages
            {
                "y",
                "x"
            };

var messagesAddStringInitializer = new StatusMessages

{

"y",

"x"

};

In addition it is even possible to use a mix of Add overloads

var messagesAddAndTextInitializers = new StatusMessages
            {
                new StatusMessage("y"),
                "x"
            };

var messagesAddAndTextInitializers = new StatusMessages

{

new StatusMessage("y"),

"x"

};

Add method can also have multiple arguments

public class StatusMessages : IEnumerable<StatusMessage>
{
    // rest of the code omitted for brevity
    public void Add(int statusCode, string text)
    {
        this.Add(new StatusMessage(text) { StatusCode = statusCode });
    }
    
    public void Add(int statusCode, string text, string sourceSystem)
    {
        this.Add(new StatusMessage(text) { StatusCode = statusCode,SourceSystem = sourceSystem });
    }
    // rest of the code omitted for brevity
}

public class StatusMessages : IEnumerable<StatusMessage>

{

// rest of the code omitted for brevity

public void Add(int statusCode, string text)

{

this.Add(new StatusMessage(text) { StatusCode = statusCode });

}

public void Add(int statusCode, string text, string sourceSystem)

{

this.Add(new StatusMessage(text) { StatusCode = statusCode,SourceSystem = sourceSystem });

}

// rest of the code omitted for brevity

}

in that case we are able to use this syntax

var messagesMultipleArgumentsInitializers = new StatusMessages
            {
                { 1, "x" },
                {1,"x","source" }
            };

var messagesMultipleArgumentsInitializers = new StatusMessages

{

{ 1, "x" },

{1,"x","source" }

};

The last thing I would like to point out is that Add function doesn’t have to be an instance method, we can easily implement it as an extension method and still leverage the collection initializer syntax.

namespace AbusingCollectionInitializers
{
    public static class StatusMessagesExtensions
    {
        public static void Add(this StatusMessages statusMessages, int statusCode)
        {
            statusMessages.Add(new StatusMessage() { StatusCode = statusCode });
        }
    }
}

namespace AbusingCollectionInitializers

{

public static class StatusMessagesExtensions

{

public static void Add(this StatusMessages statusMessages, int statusCode)

{

statusMessages.Add(new StatusMessage() { StatusCode = statusCode });

}

Now with proper namespace import we can write this code

using AbusingCollectionInitializers;
// rest of the code omitted for brevity
var messagesExtensionInitializers = new StatusMessages { 1,2,3 };

using AbusingCollectionInitializers;

// rest of the code omitted for brevity

var messagesExtensionInitializers = new StatusMessages { 1,2,3 };

Source code for this post can be found here

TPL – exception handling and UnobservedTaskException issue

2015-08-102016-01-30 TPodolak.NET 4.0, .NET 4.5, TPL, UnobservedTaskException1 Comment

1. Introduction

Working with Tasks is a modern way of writing asynchronous code in an easy and flexible manner. It is quite straightforward to start using them, so usually developers do not investigate thoroughly the topic. Unfortunately this often leads to unpleasant surprises – especially when it comes to exception handling. Having this in mind let’s take a look how to handle exceptions in Task and what can happen if we do it wrong.

2. Exception handling

Because of the fact that Tasks are run asynchronously we can’t just use a standard try catch block surrounding Task

public static void TryCatchBlockWrongWay()
{
    try
    {
        Task.Factory.StartNew(() => { throw new Exception("From method TryCatchBlockWrongWay"); });
    }
    catch (Exception ex)
    {
        // this will never be hit
        Console.WriteLine("Exception handled {0}", ex);
    }
}

public static void TryCatchBlockWrongWay()

{

try

{

Task.Factory.StartNew(() => { throw new Exception("From method TryCatchBlockWrongWay"); });

}

catch (Exception ex)

{

// this will never be hit

Console.WriteLine("Exception handled {0}", ex);

}

In that case catch block is unreachable (I will describe later what happens with that exception), of course we could use try catch inside Task.Factory.StartNew lambda expression but this is not always the case. Usually we want to handle exception in the caller of the Task, not inside the Task itself. There are couple of ways of achieving that – depending on the situation you can use one of the following ways. Exception are propagated to caller once you start waiting for the result of Task. So basically you can use try catch block if you wait for a Task to finish – either by accessing Result property or using Wait method

public static void HandleExceptionTryCatchResult()
{
    try
    {
        var task = Task.Factory.StartNew(() =>
        {
            throw new Exception("From method HandleExceptionTryCatchResult");
            return 1;
        });
        // do more stuff while task is running
        // do more stuff while task is running
        // do more stuff while task is running
        var result = task.Result;
    }
    catch (Exception ex)
    {
        Console.WriteLine("HandleExceptionTryCatchResult: exception handled in try catch block. Exception is {0}", ex);
    }
}

public static void HandleExceptionTryCatchWait()
{
    try
    {
        var task = Task.Factory.StartNew(() => { throw new Exception("From method HandleExceptionTryCatchWait"); });
        // do more stuff while task is running
        // do more stuff while task is running
        // do more stuff while task is running
        task.Wait();
    }
    catch (Exception ex)
    {
        Console.WriteLine("HandleExceptionTryCatchWait: exception handled in try catch block. Exception is {0}", ex);
    }
}

public static void HandleExceptionTryCatchResult()

{

try

{

var task = Task.Factory.StartNew(() =>

{

throw new Exception("From method HandleExceptionTryCatchResult");

return 1;

});

// do more stuff while task is running

var result = task.Result;

}

catch (Exception ex)

{

Console.WriteLine("HandleExceptionTryCatchResult: exception handled in try catch block. Exception is {0}", ex);

}

public static void HandleExceptionTryCatchWait()

{

try

{

var task = Task.Factory.StartNew(() => { throw new Exception("From method HandleExceptionTryCatchWait"); });

// do more stuff while task is running

task.Wait();

}

catch (Exception ex)

{

Console.WriteLine("HandleExceptionTryCatchWait: exception handled in try catch block. Exception is {0}", ex);

}

However accessing Result or calling Wait method are blocking calls, so this might not be a perfect solution for every scenario. Fortunately we can also leverage ContinueWith method which gives you an ability to specify what should be done once Task finishes processing the operation. What is more important you can configure this method to only be called if exception occurs. Nonetheless there is one crucial thing you have to remember – in order to make exception handled or observed you have to access Exception property of Task…

public static void HandleExceptionContinueWith()
{
    Task.Factory.StartNew(() => { throw new Exception("From method HandleExceptionContinueWith"); })
                .ContinueWith(val =>
                {
                    // we need to access val.Exception property otherwise unobserved exception will be thrown
                    // ReSharper disable once PossibleNullReferenceException
                    foreach (var ex in val.Exception.Flatten().InnerExceptions)
                    {
                        Console.WriteLine("HandleExceptionContinueWith: exception handled in ContinueWith. Exception is {0}", ex);
                    }
                }, TaskContinuationOptions.OnlyOnFaulted);
}

public static void HandleExceptionContinueWith()

{

Task.Factory.StartNew(() => { throw new Exception("From method HandleExceptionContinueWith"); })

.ContinueWith(val =>

{

// we need to access val.Exception property otherwise unobserved exception will be thrown

// ReSharper disable once PossibleNullReferenceException

foreach (var ex in val.Exception.Flatten().InnerExceptions)

{

Console.WriteLine("HandleExceptionContinueWith: exception handled in ContinueWith. Exception is {0}", ex);

}

}, TaskContinuationOptions.OnlyOnFaulted);

}

or call Handle method from AggregateException object

public static void HandleExceptionContinueWithAndHandleMethod()
{
    Task.Factory.StartNew(() => { throw new Exception("From method HandleExceptionContinueWith"); })
                .ContinueWith(val =>
                {
                    val.Exception.Handle(ex =>
                    {
                        Console.WriteLine("HandleExceptionContinueWith: exception handled in AggregateException.Handle. Exception is {0}", ex);
                        return true;
                    });
                }, TaskContinuationOptions.OnlyOnFaulted);
}

public static void HandleExceptionContinueWithAndHandleMethod()

{

Task.Factory.StartNew(() => { throw new Exception("From method HandleExceptionContinueWith"); })

.ContinueWith(val =>

{

val.Exception.Handle(ex =>

{

Console.WriteLine("HandleExceptionContinueWith: exception handled in AggregateException.Handle. Exception is {0}", ex);

return true;

});

}, TaskContinuationOptions.OnlyOnFaulted);

}

Otherwise exception will not be handled which may cause a lot of troubles described in section 3 of this post. Lastly if you use .NET 4.5 you can also just use async await and try catch block

// called from Main
public static async void HandleExceptionTryCatchAwait()
{
    try
    {
        await HandleExceptionTryCatchAwaitInternal();
    }
    catch (Exception ex)
    {
        Console.WriteLine("HandleExceptionTryCatchAwait: exception handled in try catch block");
    }
}

private static async Task<int> HandleExceptionTryCatchAwaitInternal()
{
    return await Task.Factory.StartNew(() =>
    {
        throw new Exception();
        return 1;
    }, TaskCreationOptions.LongRunning);
}

// called from Main

public static async void HandleExceptionTryCatchAwait()

{

try

{

await HandleExceptionTryCatchAwaitInternal();

}

catch (Exception ex)

{

Console.WriteLine("HandleExceptionTryCatchAwait: exception handled in try catch block");

}

private static async Task<int> HandleExceptionTryCatchAwaitInternal()

{

return await Task.Factory.StartNew(() =>

{

throw new Exception();

return 1;

}, TaskCreationOptions.LongRunning);

}

3. Handling UnobservedTaskException

If it happens that exception thrown by Task is not handled, once the Task is garbage-collected, finalizer thread will throw UnobservedTaskException.

Task.Factory.StartNew(() => { throw new Exception("fire-and-forget no exception handling"); });
using (var autoresetEvent = new AutoResetEvent(false))
{
    //wait for task to run
    autoresetEvent.WaitOne(TimeSpan.FromSeconds(2));
}

Console.WriteLine("GC: Collecting");
GC.Collect();
GC.WaitForPendingFinalizers();
Console.WriteLine("GC: Collected");

Task.Factory.StartNew(() => { throw new Exception("fire-and-forget no exception handling"); });

using (var autoresetEvent = new AutoResetEvent(false))

{

//wait for task to run

autoresetEvent.WaitOne(TimeSpan.FromSeconds(2));

}

Console.WriteLine("GC: Collecting");

GC.Collect();

GC.WaitForPendingFinalizers();

Console.WriteLine("GC: Collected");

The implication of this depends on framework we are running our application on. If you run your app on .NET 4.5 or later version, with default escalation policy, TaskScheduler.UnobservedTaskException event will be raised and basically that is all. No more further problems, so basically you may not even realize that there is something like UnobservedTaskException. However if we add this entry

<runtime>
    <ThrowUnobservedTaskExceptions enabled="true"/>
</runtime>

</runtime>

to app.configour process will be killed once UnobservedTaskExceptionis is thrown.

The problem arises in .NET 4.0 (if you run your app on .NET 4.0 not only compile it against this framework version), in this version of framework default escalation policy is very strict and will kill our process once the UnobservedTaskException is thrown by finalizer thread. Furthermore you cannot change this policy using app.config. Fortunately there is a one last chance to handle UnobservedExceptions and prevent our process from being killed. All you have to do is to wire up TaskScheduler.UnobservedTaskException static event handler and then set exception to observed state

TaskScheduler.UnobservedTaskException += TaskScheduler_UnobservedTaskException;
private static void TaskScheduler_UnobservedTaskException(object sender, UnobservedTaskExceptionEventArgs e)
{
    e.SetObserved();
}

TaskScheduler.UnobservedTaskException += TaskScheduler_UnobservedTaskException;

private static void TaskScheduler_UnobservedTaskException(object sender, UnobservedTaskExceptionEventArgs e)

{

e.SetObserved();

}

There is one more thing to clarify. You can compile your library against .NET 4.0 but if you have .NET 4.5 installed on your machine, your application is launched and run on .NET 4.5. This means that escalation policy from .NET 4.5 will be used – so by default process will not be killed. In order to simulate pure .NET 4.0 behavior while having .NET 4.5 installed you have to add

<runtime>
    <ThrowUnobservedTaskExceptions enabled="true"/>
</runtime>

</runtime>

in your app.config as it was mentioned before. Otherwise you would have to uninstall .NET 4.5 in order to, for example reproduce production issue. Source code for this post can be found here

Easy way to suppress code analysis warnings

2015-08-102016-01-30 TPodolak.NET, c#, code analysis

Everyone who has ever been using a code analysis knows that sometimes it is hard to follow the Microsoft coding guidelines and it is necessary to suppress some warnings. For me it always was a painful operation because I didn’t know any automated way of doing that. So basically I had to find the warning in the MSDN, copy category, code and other necessary stuff and then manually add appropriate attribute in code. Fortunately a friend of mine yesterday showed me a simple trick to generate this attribute with couple of mouse clicks. All you have to do is to right-click on warning message and choose Suppress Message context menu …

There are two options in there. The first option – In Source, will add attribute directly in the code

and the second one – In Suppression File, will create GlobalSuppressoins.cs file with assembly attribute which suppresses given warning in entire assembly

.NET BLOG

.NET, C# blog

Using async/await with IAsyncResult pattern

EntityFramework – SQLException during database migration

Abusing collection initializers

TPL – exception handling and UnobservedTaskException issue

1. Introduction

2. Exception handling

3. Handling UnobservedTaskException

Easy way to suppress code analysis warnings