Search code examples
javascriptwindows-runtimeportable-class-librarywinrt-async

Call async method in portable code library from windows runtime component

Background

I am building an app that will be available on both Windows 8 (as a store app) and Windows 7 (as a WPF desktop app). These apps will allows browsing a bunch (some 500+ application "pages") of content.

While I cannot share much of the code between them, I do want to share as much as possible. So I have created a Portable Code Library (PCL) targeting .NET 4.5, Silverlight 4+, and Windows 8. Since the Win 8 app is written in JavaScript (for various reasons, not part of this question), I also have a Windows Runtime Component which acts as a proxy between the JavaScript and PCL. In other words, async calls from JavaScript first invoke a method on the WinRT component, which then calls the corresponding method in the PCL.

Problem

In order to support async operations in the PCL, I installed the Microsoft.Bcl and Microsoft.Bcl.Async packages via NuGet. These, among other things, defind the Task and Task<> classes necessary to async methods, but they do so in their own assemblies. The WinRT component does not need those libraries as Task and Task<> are already defined for it. The problem is when I add code in the WinRT component to call an Async method in the PCL that returns a Task<> object, I get the following build error:

WINMDEXP : error WME1007: Could not resolve reference 'Assembly(Name=System.Threading.Tasks, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)'.

What I Have Tried

I have tried lots of things, but the main two that might come up are:

  1. Modifying the app.Config for the WinRT component to add a bindingRedirect for the assembly.
  2. Making the PCL call externally non-async by getting the Task object back from the async call it does internally and calling Wait() on it. The Wait either never returns to throws a cryptic exception.

So, any thoughts on how to accomplish this?

Thanks,
Dave Parker

Solution

  • This is a known issue with WinMDExp which has been fixed in Visual Studio 2013.

    We've provided a workaround on this page (see Issue 7): http://blogs.msdn.com/b/bclteam/p/asynctargetingpackkb.aspx.