Microsoft.Bcl.Async is Now Stable

Microsoft.Bcl.Async is Now Stable

Rate This
  • Comments 49

It’s done. About five months ago, we shipped our Microsoft.Bcl.Async NuGet package which provides support for the async/await keywords for pre-.NET 4.5 platforms, such as .NET 4, Silverlight 4, and Windows Phone 7.5. Of course, this includes support for portable class libraries as well.

We believe we’ve baked Microsoft.Bcl.Async enough to flip the switch and mark it as stable. This might not sound like a big deal but it is the NuGet equivalent of shipping an RTM.

C-3PO: "Sir, it's quite possible this package is not entirely stable."

Han Solo: "Not entirely stable? Well, I'm glad you're here to tell us

these things. Chewie, take the professor in the back and

show him how to upgrade the NuGet package!"

--- Star Wars as Immo remembers it

What’s the big deal with being stable?

Being stable means the owner of that package states that API and functionality are unlikely to change and therefore suitable for use in production. This also enables 3rd parties to publish stable NuGet packages that depend on our package because NuGet prevents stable packages from depending on pre-release packages.

What about Microsoft.CompilerServices.AsyncTargetingPack?

Before we shipped Microsoft.Bcl.Async we shipped another NuGet package which was provided by the language team to gather feedback on the async and await keywords (“Async Targeting Pack”)

Our stable release of Microsoft.Bcl.Async officially supersedes the Async Targeting Pack. We haven’t removed it, but we unlisted it on NuGet so that new developers aren’t accidentally using the old version. We’ve also added a readme.txt which is automatically displayed by VS when existing consumers upgrade their package references.

Fixed Issues

The majority of customer issues we’ve seen was due to two issues:

  1. Outdated version of NuGet. In order to use the Async package from a portable class library, you need to run the NuGet 2.1 or higher. To address this in the future, we have worked with the NuGet team and NuGet 2.3 will add this ability. For now, you will need to know to install an updated version of NuGet (see instructions in section “How to Upgrade” below).
  2. Missing reference to the async package from all referencing projects. In order to make the async functionality work across all platforms, we make use of a CLR feature called assembly unification. For that to work properly, all projects must have a reference to the Async NuGet package. Since this can be easy to forget, we’ve added a warning mechanism to our package that tells you what to do. I’ll discuss this in more detail below.

After upgrading, you will see the following build warning:


After fixing this, you might see the following warnings:

In both cases, the project that causes the warning is missing a NuGet package reference. Adding these references will fix the warnings.

Tip: If your solution contains many projects, you may want bulk-add the async packages to several projects at once. You can do this by right clicking your solution and selecting Manage NuGet Packages for Solution. Select the NuGet package and click Manage. A dialog appears that enables you to select the projects you want to update.

Add references for Microsoft.Bcl, Microsoft.Bcl.Async, and Microsoft.Bcl.Build to all projects that show the warnings mentioned previously.


We’ve added some branding to make our packages easier to recognize. Our dotnetframework user now displays the .NET gravatar.


and so does our async NuGet package:


How to Upgrade

Important: Since our package contains portable class libraries, you need to use NuGet 2.1 or higher. You can check whether you have the latest version by going to Tools | Extensions and Updates. When the Extensions and Updates dialog opens, select Updates | Visual Studio Gallery and look for an entry titled NuGet Package Manager.

In order to upgrade to the RTM version, right click your project and select Manage NuGet Packages. In the resulting dialog, select the Updates section on the left hand side. In the center, the Async NuGet package should show up. Simply click the Update button.


Microsoft.Bcl.Async is now stable which means you can use it in production. Of course, software is never truly done, so we still want to hear from you if things don’t work for you. You can contact us via comments under this blog posts or via our NuGet contact page. Also, make sure to check out the known issues list.

  • Thanks, but doesn't work in FX4. Create a new FX4 project, install package Microsoft.Bcl and immediately attempt to build. I get:

    Error 1 The "EnsureBindingRedirects" task failed unexpectedly.

    System.MissingMethodException: Method not found: 'System.String System.Reflection.AssemblyName.get_CultureName()'.

      at Roxel.BuildTasks.EnsureBindingRedirects.MergeBindingRedirectsForReferences()

      at Roxel.BuildTasks.EnsureBindingRedirects.Execute()

      at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()

      at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask, Boolean& taskResult) BclTest

  • I had the same problem as described in The only thing that worked for me was going back to the old async targeting pack.

  • Vagif Abilov: Issues with package Restore. Please see Issue 5 in our known issues list:

    @Amenti, Haacked and @Nguy?n: Issue with non-AnyCPU configurations. we've updated our version of Microsoft.Bcl.Build. Updating that package should solve this issue.

    @Richard Szalay: You can send me an email under immol at microsoft dot com. Thanks!

    @Wolfgang Fuerst: We're looking into it. At first glance it seems like a unification issue in the VS static code analysis feature (FxCop). We've contacted the owners of it. Unfortunately, I don't think there is a workaround other than disabling code analysis for those projects :-(

    @Kent Boogaart: Thanks for reporting it. The root cause is that our infrastructure packages (such as Microsoft.Bcl.Build) require Visual Studio 2012/.NET 4.5. We've could probably recompile those packages against .NET 4 but in order to use the async/await keywords you need it to compile your code with .NET 4.5 build & compiler anyways, so this wouldn't help your particular case.

    @Werner: Which platform are you targeting? Could be that your application project is missing a reference to Microsoft.Bcl.Async?

  • Microsoft.Bcl.Async is just awsome. :)

    I'm making number of presentations in Slovenia presenting this for PCL. :)

  • @Immo: Issue with non-AnyCPU configurations. we've updated our version of Microsoft.Bcl.Build. Updating that package should solve this issue.

    It works great now. Thanks a lot. :)

  • I get the following error when trying to build on the MSBuild server for a couple of my projects.  It builds fine on my machine.   What could I be missing up there?

    ...\Sources\packages\Microsoft.Bcl.Build.1.0.5\tools\Microsoft.Bcl.Build.targets (74): The "EnsureBindingRedirects" task failed unexpectedly. System.MissingMethodException: Method not found: 'System.String System.Reflection.AssemblyName.get_CultureName()'.    at Roxel.BuildTasks.EnsureBindingRedirects.MergeBindingRedirectsForReferences()    at Roxel.BuildTasks.EnsureBindingRedirects.Execute()    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask, Boolean& taskResult)

    It's strange.  Due to a dependency we took with a project we needed to add async to around 40 other projects in the solution (out of the 110).  Only a couple of the projects flag with the error above when building on TFS/MSBuild server.  

    The other issue I'm running into is now my SlowCheetah transforms no longer work at run time.  I have to comment out the bcl.targets import in the csproj project file of the exe project as a work around.  Which isn't a long term solution.



  • @Jernej Kavka and Amenti: Thanks for the kind words -- we are glad you are as excited as we are!

    @NW: This looks like you are building on a .NET 4 machine. Although we do support targeting .NET 4, we require the .NET 4.5 tools. This would also be required, if, for example, you try to use the new async/await keywords.

  • I have a multi-assembly VB.NET application (VS2012, .NET 4.0), and I've added the three Microsoft.Bcl(.Async, .Build) NuGet packages to all projects in the solution.  I am trying to use ClickOnce to deploy the executable, but System.Runtime.dll and System.Threading.Tasks.dll are not being included in the ClickOnce deployment.  They are not even listed in the "Application Files..." dialog, even though they are referenced by the project and "Copy Local" is true.  Any ideas why they aren't being included?  Is there some way to add them manually?

  • I was having problems loading the solution when adding this package if my project was installed in a folder that contains the # (sharp) symbol (e.g. C# Projects\ProjectName\...). It could not find the correct path to the package.

    Also, as somebody mentioned before, I had to manually add a reference to System.Net for the package to correctly install in the project.

    I thought I'd report this stuff.

  • @Mark: Thanks, we are looking into it.

    @Fog.Gene: Thanks for reporting this issue. I can reproduce it and filed a bug. We'll fix it in the next update.

  • Hi guys,

    Is there a reason that Microsoft.Threading.Tasks required System.Core 2.0.5 rather than 4.0? I just had to remove all asynchronous code from an application because production didn't have the assembly available.

    Is there a recommended way to get System.Core, 2.0.5 deployed with an application?


  • @Richard: Yes, this is by-design. The lower version number ensures compatibility with other platforms, such as Silverlight. System.Core 2.0.5 unifies with System.Core 4 so it is also compatible with .NET 4. Any reason you are concerned about the version number?

  • @Immo The version number itself doesn't bother me, per se. However, having simply added the nuget package, when we deploy into our production environment that System.Core assembly is apparently not available on that server and an assembly binding exception is thrown.

    Any thoughts on how to configure the project so that System.Core 2.0.5 is deployed with the application?

  • @Richard: That sounds like a problem. Can you contact me at immol at microsoft dot com? We may need more details to repro this. If you're sending mail it would be helpful if you include the platform you're targeting.


  • I'm having the following problem: When the Microsoft.Bcl.Build.Tasks.dll is not present in the packages folder when VS starts, i'm getting build errors like "Error 6 The "ValidatePackageReferences" task could not be loaded from the assembly". NuGet restores the DLL, but a rebuild or restarting of VS does not solve the errors. Only after a restart of the whole system does the build process work again. (I make sure "Microsoft.Bcl.Build.targets" is always present, as described in Issue 5 of the known issues.)

Page 3 of 4 (49 items) 1234