Microsoft.Bcl.Async is Now Stable
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”)
https://www.nuget.org/packages/Microsoft.CompilerServices.AsyncTargetingPack
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:
- 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).
- 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.
Branding
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.
Summary
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.
Comments
Anonymous
April 17, 2013
Thanks, this is very helpful for WP7 development. Just updated to the stable release over NuGet.Anonymous
April 17, 2013
Great work ... I'm absolutely loving the use of NuGet for deploying .NET libs, very very developer friendly!Anonymous
April 17, 2013
thanks. Now we have an upgrade path.Anonymous
April 17, 2013
Please add support for Task based WCF Client generation.Anonymous
April 17, 2013
Fantastic news! This is really helping me out writing my WP7 app that has loads of asynchronous network communication. Now I can publish it!Anonymous
April 17, 2013
Great! Any news about Http Client Libraries hitting RTM soon?Anonymous
April 17, 2013
Hello, having a issue with a Library (.NET 4) that is use BCL. If a .NET 4.5 executable tries to add a references (based on the warning that it is required) to Microsoft.Bcl.Async I end up with a compiler error that this is not allowed. Any solution for that?Anonymous
April 18, 2013
BG: Can you provide more information? What compiler error are you getting? Did you use NuGet to install the package to the .NET 4.5 project? David Kean (MSFT)Anonymous
April 18, 2013
Awesome! Now let's see System.Net.Http stable for WP! Keep up the great work.Anonymous
April 18, 2013
@Martin Suchan: Thanks for your interest in the portable HttpClient! We haven't finalized the release date yet but we are planning on shipping an updated version within the next three weeks or so. Right now we aren't planning on making this a stable release as we are adding substantial feature work. However, we are quite confident that the very next release after will be marked as stable.Anonymous
April 18, 2013
@BG: You should be able to fix the issue by changing the newVersion for the binding redirects in the .NET 4.5 project's app.config from 2.5.19.0 to 4.0.0.0 for System.Runtime and System.Threading.Tasks. Daniel Plaisted (MSFT)Anonymous
April 18, 2013
Our company policy is to have all development workstations offline. How can I install this and other nuget packages offline?Anonymous
April 18, 2013
@Jason R, NuGet offers you a way to create your own custom shares. So you can download packages that you need to a non development workstation and configure your dev workstations to consume packages from there, instead of the online mode.Anonymous
April 18, 2013
Is Microsoft.Bcl.Async now supported for VB Web Applications?Anonymous
April 19, 2013
Is there a planned .NET 4.1 framework update to push this DLL out to our end users?Anonymous
April 19, 2013
I think I may have found an issue with the assembly unification and mixed platform targets. I have a repro project, but the steps are pretty easy. Here's a description of my solution with two projects and platform targets. Solution.sln > WPFProject.exe (x86) > SomeClassLib (AnyCPU) WPFProject.exe references SomeClassLib which is a C# class lib. I installed Microsoft.Bcl.Async into both projects. I changed the Active CPU configuration to x86. When I build the project, I get the following error. 1>------ Skipped Build: Project: SomeClassLibrary, Configuration: Debug Any CPU ------ 1>Project not selected to build for this solution configuration 2>------ Build started: Project: WpfApplication1, Configuration: Debug x86 ------ 2>C:WindowsMicrosoft.NETFrameworkv4.0.30319Microsoft.Common.targets(609,5): error : The OutputPath property is not set for project 'SomeClassLibrary.csproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' Platform='x86'. This error may also appear if some other project is trying to follow a project-to-project reference to this project, this project has been unloaded or is not included in the solution, and the referencing project does not build using the same or an equivalent Configuration or Platform. Build has been canceled. Build Summary
00:00.386 - Failed - Debug x86 - WpfApplication1WpfApplication1.csproj Total build time: 00:00.404 ========== Build: 0 succeeded or up-to-date, 1 failed, 1 skipped ========== Any ideas?
Anonymous
April 19, 2013
I should add that the solution built just fine before I installed the Microsoft.Bcl.Async package. And it builds if I uninstall all the Microsoft.Bcl.* packages.Anonymous
April 19, 2013
Great news! Will it work with .NET Framework 3.5 as well?Anonymous
April 19, 2013
I have the same problem as Haacked. But I can finally build the project by changing the configurations and platform so that all projects have the same name. The problem occur again when I create new configuration for just 1 project. It did not happen with the pre-release version either.Anonymous
April 19, 2013
The comment has been removedAnonymous
April 19, 2013
hello Immo. i have a big problem my msdn forum account is banned and there is no reason i did not get any email message etc can you please check the issue ? social.msdn.microsoft.com/.../monstermmorpg thank youAnonymous
April 21, 2013
I'd love to work this in to our current projects that are using the AsyncTargetingPack however I would also appreciate a way to work the assembly references in without using NuGet. We don't use NuGet for anything else and we bundle all of our referenced assemblies along with the source code so working this in as a one-off just isn't that clean for us. If you get some time and know of an alternate deployment scenario, please let me know. Thanks!Anonymous
April 21, 2013
Had posted this in the HttpClient topic but that seems closed for comments now. And besides, it is the same issue that the BCL Build package won't install and stops everything else. Error is below. VS2012 with latest updates to VS and NuGet. Attempting to resolve dependency 'Microsoft.Bcl.Build (≥ 1.0.4)'. Successfully installed 'Microsoft.Bcl.Build 1.0.4'. Successfully installed 'Microsoft.Bcl 1.0.19'. Successfully uninstalled 'Microsoft.Bcl.Build 1.0.4'. Install failed. Rolling back... Could not install package 'Microsoft.Bcl.Build 1.0.4'. You are trying to install this package into a project that targets 'portable-win+net45+sl40+wp', but the package does not contain any assembly references or content files that are compatible with that framework.Anonymous
April 22, 2013
The comment has been removedAnonymous
April 22, 2013
@Furkan Gozukara: Found the right contact. For some reason, our software detected one of your posts as spam. We've fixed that so you should no longer experience any issues. Sorry for the inconvenience.Anonymous
April 22, 2013
@Shecky Boy: It looks like your Portable Class Library is targeting Windows Phone 7. The async targeting pack supports Windows Phone 7.5 and higher, so switch your PCL to target WP7.5 and try again.Anonymous
April 22, 2013
I have the same problem as @Haacked and @Nguy?n. Great that you are working on that. Thanks a lot.Anonymous
April 23, 2013
There is a problem with NuGet package restore. Bcl.Async alters project file to import Microsoft.Bcl.Async.targets from packages folder. This means that it expects the content of packages folder to be stored in the source control, and if not, projects won't load. I've manually changed projects to import targets file from ..nuget folder and copied targets file there. But there must be a better way :-)Anonymous
April 24, 2013
Hi guys, I think I've discovered a bug in the RC/final versions that causes WebClient.OpenReadTaskAsync to randomly throw a NullReferenceException when called from a background agent on Windows Phone. I've had to roll back to Microsoft.Bcl.1.0.11-beta and Microsoft.Bcl.Async.1.0.12-beta as they were the last versions to not have this behavior. Where is the best place for me to post the specifics?Anonymous
April 24, 2013
I have problems running FxCop in Wpf projects when i use Async library features. Everything except FxCop works fine. The error message i get is: 1>MSBUILD : error : CA0001 : The following error was encountered while reading module 'WpfApplication3': Could not resolve member reference: [Microsoft.Threading.Tasks, Version=1.0.12.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a]System.Threading.Tasks.TaskEx::Delay. 1> Code Analysis Complete -- 1 error(s), 0 warning(s) 1>MSBUILD : error : Code Analysis detected errors. See Code Analysis results window or log file for details. Do you have any suggestions? ThanksAnonymous
April 24, 2013
The comment has been removedAnonymous
April 26, 2013
I had the same problem as described in forums.lhotka.net/.../11927.aspx. The only thing that worked for me was going back to the old async targeting pack.Anonymous
April 26, 2013
The comment has been removedAnonymous
May 01, 2013
Microsoft.Bcl.Async is just awsome. :) I'm making number of presentations in Slovenia presenting this for PCL. :)Anonymous
May 01, 2013
@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. :)Anonymous
May 02, 2013
The comment has been removedAnonymous
May 02, 2013
@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.Anonymous
May 08, 2013
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?Anonymous
May 12, 2013
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# ProjectsProjectName...). 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 4.0.0.0 for the package to correctly install in the project. I thought I'd report this stuff.Anonymous
May 13, 2013
@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.Anonymous
May 20, 2013
The comment has been removedAnonymous
May 21, 2013
The comment has been removedAnonymous
May 21, 2013
@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?Anonymous
May 21, 2013
The comment has been removedAnonymous
May 22, 2013
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.)Anonymous
May 22, 2013
Using VS 2012 I was getting the same error like Kent Boogart for my .net 4 project. Then I found this workaround. I did have a missing culture in one of the elements. After applying the workaround it worked.
Workaround
connect.microsoft.com/.../microsoft-bcl-build-1-0-5-fails-when-dependentassembly-is-missing-a-culture-attribute Open your project's web/app.config and look for any configuration/runtime/assemblyBinding/dependentAssembly/assemblyIdentity that are missing a culture attribute and add culture="neutral". Clean and rebuild.
But now I have another minor issue where inside the app.config assemblyBinding I have a probing element that gets erased every time I build the solution!
Anonymous
June 04, 2013
Building my silverlight project is just fine. But FxCop code analysis fails with the following error. Any thoughts? Unresolved : 'Microsoft.Threading.Tasks' reference to System.Threading.Tasks, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. … The indirectly-referenced assembly 'System.Runtime, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' could not be found. This assembly is not required for analysis, however, analysis results could be incomplete. This assembly was referenced by: E:packagesMicrosoft.Bcl.Async.1.0.16libsl4Microsoft.Threading.Tasks.dll.Anonymous
June 11, 2013
When I run Code Analysis from within Visual Studio 2012 Premium, I get the following error: CA0001 Error Running Code Analysis CA0001 : The following error was encountered while reading module 'ConsoleApplication1': Could not resolve member reference: [Microsoft.Threading.Tasks, Version=1.0.12.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a]System.Threading.Tasks.TaskEx::Delay. [Errors and Warnings] (Global) Microsoft.Threading.Tasks.dll (v1.0.12) is located in the output folder together will all other dependencies and the application is running just fine. Is it a problem with code analysis? And is there any workaround or a fix in the works?Anonymous
June 13, 2013
man i've got the 2.0.5.0 type error in Win8 but KB2468871 cannot be installed in win8. what should i do...