Async Targeting Pack for Visual Studio 11 now available for .NET 4 and Silverlight 5

Async Targeting Pack for Visual Studio 11 now available for .NET 4 and Silverlight 5

Rate This
  • Comments 19

We’re happy to announce that you can now download an Async Targeting Pack for Visual Studio 11 that lets you target .NET 4 and Silverlight 5.  The included DLLs address the previously discussed issue of the Visual Studio 11 Beta compilers being incompatible with the AsyncCtpLibrary* DLLs from the Async CTP; with this targeting pack, you can use the async/await keywords with Visual Studio 11 Beta to compile for .NET 4 and Silverlight 5.  The DLLs are available via a NuGet package, with installation details available here. Enjoy!

Leave a Comment
  • Please add 2 and 1 and type the answer here:
  • Post
  • Will portable libraries work with the targeting pack or do we still need to use AsyncBridge (github.com/.../AsyncBridge) for that?

  • It does not currently support portable libraries.

  • This is great!

  • I have Windows Phone 7 apps using the Async CTP though the PC that had VS2011 on it had compatiblity problems.

    Once VS2011 supports WP7 development, perhaps this Targeting Pack will help my situation.

    For now, I use a PC that does not have VS2011 on it for my WP7 (with Async CTP) development.

  • So how do we get VS 11 to create WCF proxies that expose async compatible methods?

  • Ladislav, I'm glad you like it.

    Jonathan, the proxy generator won't generate task-based methods if you're targeting a Framework version below .NET 4.5.  You can always have the proxy generator create the APM Begin/End methods, and then use support like Task.Factory.FromAsync to get a Task to represent the APM invocation.

  • Hi Stephen

    I have a concern I have posted in some other blogs related to the Async targeting pack. Here it goes:

    In our office we created an small spike WCF solution (Server/Client) that uses a ServiceContract let's say ISomeService that has one operation contract that returns a Task<T>. For creating this we used VS 11 with the new targeting pack and of course we were targeting .NET 4 for both projects Server and Client.

    Now the problem is that even though we know WCF 4 cannot serialize Tasks our solution compiled and ran perfectly in our development PC but when testing it in an XP PC with just .NET 4 installed for obvious reasons (.NET 4.5 doesn't support XP) our bits failed with the exception that Tasks cannot be serialized etc etc. perfectly understandable since .NET 4 cannot serialize Tasks.

    Now we can avoid this and not use Task<T> returning services in WCF since we are targeting .NET 4 because we now about this problem and NOT because when we were developing and testing VS 11 even targeting .NET 4 failed, which is the behavior I will expect from VS 11 to fail when I try to run a project that targets .NET 4 the way is not supposed to be used.

    So my real concern is what kind of other problems we can be incurring in using async/await features while developing in VS 11 + Async Targeting pack even though you target .NET 4 rather than using VS 2010 + Async CTP. I mean we will be incurring into those problems since we will be developing in VS 11 thinking that we are safe because we targeted .NET 4 framework when in reality when we test our apps in an environment with just .NET 4 they can fail.

    Even worse my wild guess is that all these problems are related to the fact that .NET 4.5 is an in-place update to .NET 4 so what ever .NET 4.5 fixed, improved, added or replaced from .NET 4 will be the real stuff we will be using in our development environments with VS 11 and .NET 4.5 no matters we explicitly target .NET 4 leading to a possible failure when our apps run in a just .NET 4 environment.

    So my point here is what is the advantage to use VS 11 + Async targeting pack for targeting .NET 4 over VS 2010 + Async CTP if at the end chosing the first can shoot ourselves in the foot.

    I would really appreciate if someone knows a way to overcome this problem (I mean being able to properly use VS 11 + Async targeting pack while targeting .NET 4 knowing that our apps will safely run in for example XP), probably we did something wrong with our spike WCF solution. Any feedback will be greatly appreciated.

    by the way does anyone know if at the end .NET 4.5 will support XP this will make our lives easier ;-) or if at least the final .NET 4.5 will be a side by side installation rather than in-place update (I guess this could solve my problem as well eventhough I much prefer .NET 4.5 supporting XP so we can all make use of the new features at full capacity)

    Regards,

    Ariel

  • Congrats, it's been a long time of uncertainty that has been cleared

  • AG1ez, Task isn't serializable in either .NET 4 or in .NET 4.5.  What you're likely witnessing is that WCF in .NET 4.5 special-cases Task-returning methods for asynchronous execution, just as it does before .NET 4.5 for Begin/EndXx APM implementations.  See the blog post codebetter.com/.../building-an-async-wcf-service-in-net-4-5 for an example.

  • OK, I uninstalled VS2010 bits and then re-installed it, SP1, Async CTP, Windows Updates, WP7.1 tools, WP7.1.1, Framework 4.5 and VS2011 and everything is now OK. The Async CTP is working in my VS2010 for my WP7 apps.

    Gary

  • Hi Stephen

    Then why my project run perfectly in a PC with .NET 4.5 even though I am targeting .NET 4  I mean I am able to open a Service that host an OperationContract that returns a Task<T> and a client that is able to consume that service using Tasks. Now if the same running project I actually run it in a PC with just .NET 4 it fails when trying to open the Service Host saying that Task cannot be serialize. So I wanna know why the difference in behavior in running my project in two different PCs I should have expected the same error in both PC.

    Regards,

    Ariel

  • Hi AG1ez-

    Because on .NET 4.5, WCF recognizes Task and Task<TResult> as special return values that indicate the method should be invoked and the returned Task used to notify WCF when the operation has asynchronously completed.  This is just like how BeginXx/EndXx methods are specially-recognized by WCF, e.g. BeginXx returns an IAsyncResult, but that doesn't mean IAsyncResult is serializable.  The point here is that, yes, there is additional functionality in WCF in .NET 4.5 that makes something which doesn't work in .NET 4 start to work; it's new functionality, so it'll work with WCF in .NET 4.5 and won't work with WCF in .NET 4.  The error message you're getting from WCF in .NET 4 is because Task isn't serializable; you don't get that error message in WCF in .NET 4.5 because WCF doesn't try to serialize it, not because it is serializable (it isn't).

  • Hi Stephen

    I understand what you are saying but the problem here is that I wasn't using .NET 4.5 at all. All my projects (Server and Client) are targeting .NET 4 so I expected WCF 4 to be used right?. Now my problem is that my solution run without problems in a pc with .NET 4.5 eventhough I was targeting .NET 4. But when I run my example in a pc with only .NET 4 boom I get my exception. Now my point is that how I can safely develop in VS 11 + Async targeting pack  targeting .NET 4 if in my development computer everything will work just fine but as soon as I try it in a client PC with just .NET 4 then my app may crash because I am using something I though it will be safe to use in .NET 4 but it is not.

    Regards

    Ariel

  • Hi AG1ez-

    We're on the same page; apologies if I confused things.  I was just further elaborating on why this happens, i.e. it's not that Task is suddenly serializable in .NET 4.5, but rather that WCF in .NET 4.5 specially recognizes Task as a marker that the method should be used asynchronously.

    Note that specifically for the WCF issue, you can still use Task-returning methods, you just need to use them internally, and instead expose from your service Begin/End methods that wrap your task returning method, such as the post at blogs.msdn.com/.../10179452.aspx outlines.

    In general, these kinds of issues are possible any time a release makes internal improvements to a library or platform, even such as fixing bugs... if your development environment is more up-to-date than the target environment, you might not be testing against the same environment in which your code will actually run, and you may be taking a dependency on the improvements.  As such, it's important to test as much as possible in the target environment.  In your case, that means testing as much as possible on a machine with .NET 4.

  • I don't understand. Why can't the client-side proxy generator automatically create Task-based wrappers that just call Task.Factory.FromAsync? It appears to be a purely mechanical transformation.

Page 1 of 2 (19 items) 12