Using async/await without .NET Framework 4.5

Using async/await without .NET Framework 4.5

Rate This
  • Comments 45

[Update: We've uploaded a new version of Microsoft.Bcl.Async NuGet package. The previous version will not work correctly on Windows Phone 7.1]

Do you want to use await but don’t want to wait until you can target .NET Framework 4.5? The waiting is over and awaiting is about to begin.

Today, we are proud to announce an update to the Async Targeting Pack we had previously released. The previous targeting pack allowed you to use await when targeting .NET Framework 4.0 and Silverlight 5. Our updated targeting pack allows you to use await in Visual Studio 2012 when targeting any of the following platforms (or higher versions):

  • .NET Framework 4.0 (with KB2468871)
  • Silverlight 4
  • Windows Phone 7.5
  • and portable class libraries targeting those platforms

So effectively we added support for Windows Phone 7.5, Silverlight 4, and portable class libraries.

Hang on – isn’t this simply a language feature anyways?

Yes and no. It’s very tempting to think of the new async/await keywords in C# and Visual Basic as pure language features. And to an extent this is true: the compiler has to do some heavy lifting to turn your code into something that can await operations.

With this mindset developers expect to be able to use await as soon as they use Visual Studio 2012 – independent from the .NET platform they are targeting. However, if you consider how most language features are implemented, it becomes quickly clear that this is not a given. Many language constructs require the .NET platform to expose certain APIs in order to support them. For example, extension methods require the ExtensionAttribute and foreach depends on IEnumerable. In the case of await, both languages require Task and some plumbing that make them awaitable.

What do I need for await?

In order to use await you need two components:

  1. Visual Studio 2012
  2. Some specific .NET APIs

In case you are targeting any of our newer platforms (i.e. .NET 4.5 or .NET for Window Store apps) the second point is a no-op – those platforms already have the required APIs. When you target any of the platforms that shipped before Visual Studio 2012, that is .NET Framework 4.0, Silverlight 4, and Windows Phone 7.5, you need to add a NuGet package that provides those APIs.

Note: If you are a phone developer, you are probably aware of the fact that Visual Studio 2012 doesn’t allow you to build phone apps yet – stay tuned. See this post for details.

Before consuming the packages, make sure you've got the NuGet 2.1 or newer installed.

To add a reference to our NuGet Package, right click the project, select “Manage Package References” and search for Microsoft.Bcl.Async. Make sure you selected the “Online” tab on the left hand side and the top left drop down says “Include Prerelease”.

 Of course, you can also install the package via the Package Manager Console by running the following command:

install-package Microsoft.Bcl.Async –pre

Please note this package is marked as prerelease software – that is, there are some rough edges to be expected. We’ve published the known issues here. As usual, we’d like to know when you are having trouble using it. Simply use the comment section under this blog post.

Happy awaiting!

  • Great, can't wait to test it. Especially the support in Portable Class Libraries is perfect.

  • This is great news! I used the previous version of the package in a small Silverlight 5 app, and the improvement in code clarity with async was huge.

  • Just to be really picky, foreach doesn't require IEnumerable, just a suitable GetEnumerator() method (section 8.8.4 of the C# language specification).

  • Hey, welcome to the club at last :-)

    As I'm sure the blog author knows, C# async/await is a version of the F# async language feature (, which has been available on VS2008, VS2010 and VS2012 since 2007, and can even be used with .NET 2.0 and .NET 3.5.

    But more seriously, it is awesome to see this programming language feature spreading like wildfire. When we first did the feature in F# at Microsoft Research in 2007 (and the Task library by Daan Leijen too around the same time) we had no idea how massively successful it would be and how fast it would spread. I remember presenting it to Mads Torgorsen, Anders and others in 2008 at MSR Cambridge. Then Mads and many others worked on Anders, and it made its way into C# in 2012.  

    I'm extremely glad for the sake of the whole software industry that this feature is spreading so rapidly, thanks to the incredibly hard ongoing work of people like Immo in the Microsoft CLR and language teams.

  • Thanks guys. It's great to see support for PCL being added!

    A little hiccup I've run into in a .NET 4 project is that if you want to use the async extensions to WebRequest/WebResponse, you need to manually add a reference to System.Net Version, or you get compile errors.

    Also, there seems to be a problem with Resharper and the WebRequest/WebResponse async stuff; Resharper reports compile errors where there aren't any. I've reported it to them here:

  • Thank you!!!!

  • @John: You are absolutely right. For the sake of simplicity I didn't want to go too deep into how C# enables foreach. I was looking for some simple, and yet well known examples for languages having a dependency on a an API. A better example would probably have been VB XML literal's dependency on XElement.

    @Don: Thanks for the kind words. Since you named me: in fact, all the hard work has been done by the language teams and my BCL colleagues -- they deserve all the credit.

    @Daniel: The issue regarding System.Net.dll is a good one. We should add it to the list of known issues. To be fair, this issue is not new. Whenever you are referencing APIs whose surface area dependencies are defined in an assembly that isn't referenced the compilers give you an error telling the assembly that you need to reference.

    The ReSharper issue is an interesting one -- thanks for reporting it!

  • Thanks so much!!

  • Hi Immo, a couple of questions since we basically just added support for async test methods in NUnit.

    - We are relying on the presence of the System.Runtime.CompilerServices.AsyncStateMachineAttribute to identify them, does this still hold true here?

    - We are interacting with a thread's SynchronizationContext to handle async void test methods (which normally would not be awaitable). Do async void methods interact with the synchronization context in the same way here as well? (Post, OperationStarted, OperationCompleted)

    Thanks, Simone

  • Thank you very much for the Silverlight 4 support! however I have come across a very annoying bug. ConfigureAwait doesn't work in Silverlight 4, nor Silverlight 5:

    This pack & the existing async targeting pack have the same issue in Silverlight 4 and Silverlight 5 respectively!

  • @Simone:

    Regarding detecting async methods:, the answer is yes. We've provided that type exactly for that purpose, that is detetcing async methods via static analysis.

    Regaring sync context: can you provide more details? What do you mean by "interacting with async void methods". Please shoot me an email at immol at microsoft dot com. Thanks.


    Thanks for reporting the issue via connect. We'll take a look and come back to you there.

  • Hi! Please consider reviewing this bug:

    Thank you!

  • @Sgt.Riggs: Thanks for reporting the issue via connect. I just had a quick look and seems like a bug. We'll look into it.

  • So, will Windows Phone 7 (not 8) development be possible in Visual Studio 2012? That would be really great!

  • @Konamiman: Yes, for 7.5.

    "The Windows Phone SDK 8.0 is built on top of Visual Studio 2012, and will give you the ability to build applications and games that target both Windows Phone 8 as well as Windows Phone 7.5."

    For more details have at look at this post:

Page 1 of 3 (45 items) 123