Monthly Archives: April 2017

Consuming a WebAPI Endpoint on Localhost from the Visual Studio Android Emulator

It is highly likely that any Xamarin Android application that you build will be consuming a RESTful API. And when you are developing the application, you don’t want to have to deploy that API to the Internet somewhere. You just want to run it up on localhost. It will make for a much faster development experience, as you will be able to iterate a lot quicker.

There’s not an abundance of help from the community on this and it took me about a day to figure it all out. So, hopefully this post will short-circuit the task for you.

My first port of call was this great post by the formidable Brian Noyes.

But it did not get me the whole way there. He left out a few important details, such as the fact that you need to run Visual Studio (“VS”) on elevated privileges to host the API on a IP address other than localhost. Otherwise, you will get the following error message Unable to connect to web server ‘IIS Express’.

So lets get to it…

You’ll need to install the Visual Studio emulator for Android which you can read about here. Note that it uses HyperV. This is great, but has a consequence. If you have VMWare’s VMWare player on your machine, you can forget about running any VMWare VMs as they are incompatible with HyperV. It is either one virtualization technology or the other. As the Visual Studio Android emulator is so good and fast, I ditched VMWare on my system.

So, here are the steps you need to do and I’ll assume you have already created an ASP.NET Core WebAPI project running on the full .NET framework (and not .NET Core).

  1. In this step, you need to configure your WebAPI project to serve up the API on a particular IP address (which is not localhost). Your Xamarin app needs to hit that IP address. Obviously, however, when production-ready, it will hit the full url of your production deployment of the Web API application. (I’m guessing you have already worked out that the localhost of your Android app is the Android device itself. So, localhost won’t help you.). To host the Web API on such an IP Address, open the applicationhost.config file, which lives in the hidden folder called .vs in the root directory of your ASP.NET Core solution (in a subfolder called config). Look for a bindings element inside the site element for your site and add a binding for; something like:
           <binding protocol="http" bindingInformation="*:57971:localhost" />					
           <binding protocol="http" bindingInformation="*:57971:" />

    Note the IP Address, which I will discuss in the next step. Remember, you have to run Visual Studio with elevated privileges to host the Web API on that IP address. So when you fire up Visual Studio, do it with Run as Administrator.

  2. From Noyes’ post, “With the VS Android Emulator running, click on the double caret >> button in the side toolbar. This opens up the settings UI, one of which is for Network.” Now, look through the Desktop Adapters for one which has the IP address For me, that was Desktop Adapter #4. It may have a different number for you. This is the one you have to use. It has to have an IP address of So, this step is really more to confirm that one of the Desktop Adapters has that IP address. The mistake I made was that Noyes’ article stressed the usage of Desktop Adapter #2. But it is the IP address which is important, not which adapter number it has. Once you have confirmed that is the IP Address for one of the adapters, you can move to the next step. Oh and obviously all calls to your local WebAPI in your Xamarin app should be made to that IP address.
  3. The last thing you need to do is open a port in your dev machine’s firewall for the port upon which your WebAPI project is listening. So, if you are running it on IIS Express on port 57543, then you need to create an inbound firewall rule permitting TCP connections to that port. This makes perfect sense, because the Emulator is a different machine, to all intents and purposes. It’s a stand alone virtual machine running in HyperV. And it is calling into your dev machine’s localhost services externally.

There’s not many steps, but the trick is figuring them out! Hopefully that saves you some time!