Question

I've started work on a Windows 8 store app that needs to communicate with a WCF service running as a Windows Service on a Windows 7 server. The binding is net.tcp, with no security (yet). I've also gone into the Package.appxmanifest file and checked "Internet (Client)" and "Private Networks (Client and Server)" in both my main application project and in a unit test project. This works fine in the unit test project, I can communicate with my WCF service running on the Windows 7 machine, but I'm unable to access the service in the Windows 8 app itself. The application just hangs on the call to the webservice proxy. Am I just missing something simple with permissions / manifest capabilities ?

EDIT: I've actually got it working. My service interface returned a Task<IList<MyDataObj>> and the implementation was asynchronous (used the async keyword on the method implementation). When I ran it in the unit test, I would call GetItems(), then Wait() on the returned Task. Copying this to the app, it wouldn't work. When I changed my code in the app around and awaited the task call instead, the call was made to the WCF service. My question at this point is, what's the difference between the two environments and what would cause the call to just hang ?

Was it helpful?

Solution

I explain this deadlock situation on my blog and in an MSDN article.

The short summary is that await (by default) will capture the current context and resume the async method within that context.

In UI apps, that context is a UI context, but if you are blocking the thread with a call to Wait, then the async method can't re-enter the UI context to complete.

In (most) unit testing frameworks, the context is a thread pool context, so the Wait only blocks one thread pool thread and the async method can continue on another one.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top