Dave is Getting Upset: Episode 1–Trying to get my Windows Phone to Talk to my Locally Running .NET Backend Mobile Service

  • Article

“Dave is Getting Upset” will be a series of posts from me as I go through the trials and tribulations of trying to build apps with technologies that are new to me

Last week I started working on an idea that I have for a Mobile Service/Mobile App. I am working with the newly introduced .NET Backend for Azure Mobile Services. I started implementing the service and a Windows Phone client app for it and ran into a roadblock with debugging. Here are the configurations I could debug:

  • The locally running Mobile Service via browser (i.e. what launches when you F5 the project)
  • My connected Windows Phone device (i.e. my phone is plugged in and when I F5 the app launches on the phone) hitting the published Mobile Service in Azure

Here’s what I couldn’t do:

  • Have my phone hit the locally running Mobile Service client.

When I tried to do this here’s what I got:

Microsoft.WindowsAzure.MobileServices.MobileServiceInvalidOperationException: The request could not be completed.  (Unauthorized)

Now I will admit that when I started implementing my service, I didn’t read far enough on the Get started with data in Mobile Services topic to get to the section titled “Test the Windows Phone app with the service hosted locally” to find out that I needed to update my applicationhost.config file and create a firewall rule so that the phone app could hit my IIS Express, but the Unauthorized error I was getting after I fixed that up. Scratching my head a bit about this error I remembered earlier in my experience that I got prompted for credentials when I tried to hit my Azure-published mobile service directly through the browser. I found out that if you enter your application key as the password on this prompt, you will pass the authentication. So that got me wondering about if I needed to add the Mobile Service’s application key when I new’d up my MobileServiceClient from the phone app. I tried that, which by itself didn’t work. After I thought “well that’s not going to work because my locally deployed service doesn’t know anything about that key, it’s an Azure setting. And besides, the service works fine when I hit it through the browser that launches from VS when I F5”.

Well, I was more or less on the right track. After much web searching I finally came across a forum post with the answer:

You need to specify the application key of the service in the Web.config file:

  <add key="MS_ApplicationKey" value="Overriden by portal settings" />

If you run the service within Visual Studio, you don't need these values, and every request will pass. When you deploy the service on Azure, these values are overriden with the correct values. But, if you deploy the Mobile Service on your local IIS, you need to manually set them, and be sure that they match the values you enter in the client.

After changing the MS_ApplicationKey value in the web.config and also updating my phone client app to specify the application key in the MobileServiceClient constructor, I was able to hit the service from the phone!

Huge thanks to @marcominerva for posting the answer in the forum post. I will definitely be logging a bug to get the boilerplate code generated for a Mobile Service to include the application key in both places that I needed to add it.