Code Mill Minute: Debugging With Visual Studio ... But Not From Windows
The Situation
You need to debug a web based project running in Visual Studio – but the thing you want to initiate the debugging from isn’t a web browser running on Windows… Let’s say it’s a physical iPad – or maybe an iOS simulator running on a Mac and Windows itself is virtualized running from Parallels.
Every now and then I come across the following situation where I need to accomplish something similar:
- Building & debugging a Xamarin based app from OS X using Xamarin Studio
- Building & debugging a REST web service from Windows using Visual Studio – Windows is virtualized and running from Parallels
- Need to hit breakpoints in the Visual Studio code that are initiated by either the iOS simulator, Android emulator or on device
- … OR if I”m building a website, I just need to see how it looks on a real device
And every time I initially have to setup the environment to support such a situation – I have to stop and think to myself … how did I do that before?
So in hopes that by writing it down the steps get burned into my brain, and that these steps help somebody else from wracking their brain … here they are … how to debug Visual Studio code, but not from Windows:
The Steps
Step 0: Running Parallels? Set the networking mode to “bridged”. This will give your virtualized Windows an IP on the subnet just as any other machine, instead of a virtual one that only the host machine can see. We’ll then have an IP address that other devices on the same subnet can hit.
Of course this comes with the disclaimer that once you do this, Windows can be seen by the masses. But we’re all Professional Software Developers here, so what could go wrong?
To enable bridged networking – while the VM is running, you can go to the device menu of the Parallels window, select Network 1, then Bridged Network. You can select either the Default Adapter or the specific adapter that you’ll be accessing the network with the most often.
Running VMWare? Go out and by Parallels 🙂 But if that isn’t reasonable … a quick Google turns up several articles on how to enable bridged networking there as well.
The rest of these steps will apply regardless of whether you’re running Windows in a VM or not.
**Step 1:** Find out the IP address of your machine. Just open a command prompt and type: `ipconfig` and then note the IP address.Step 2: Assuming the Visual Studio solution is already setup and ready to go, we need to tell IIS express to accept connections from not only requests bound to localhost, but also the IP address from step 1. We’ll need to modify the applicationhost.config file. The trick is to find it…
When in VS2013 or below – it will be located in ~/Documents/IISExpress/config. VS2015 moves it on us though and puts it into a “.vs” folder within the solution folder structure itself. Regardless, once you find it, the modifications are the same.
Under the configuration->system.applicationHost->sites
node will be a “site” node for the application we need to debug. We’ll want to add a new node to the “bindings” so it looks similar to the following:
<site name="WebApplication1" id="20">
<application path="/" applicationPool="Clr4IntegratedAppPool">
<virtualDirectory path="/" physicalPath="C:UsersmsoucoupDesktopWebApplication1WebApplication1" />
</application>
<bindings>
<binding protocol="http" bindingInformation="*:49235:localhost" />
<!-- THIS IS THE NEW PART-->
<binding protocol="http" bindingInformation="*:49235:10.0.1.30"/>
</bindings>
</site>
What we did was tell IISExpress to accept connections on port 49235 while running on IP address 10.0.1.30.
Step 3: Open the firewall. Even though we’re all Professional Software Developers here and nothing could possibly go wrong if we turn off the firewall completely, we should just open up the port we need, in this case 49235.
- Open “Windows Firewall With Advanced Security”.
- On the right hand side click “New Rule…” We want to open a specific port – this this case 49235
- Then click “allow the connection” on the next screen.
- Specify when you want the rule to apply – most likely just when you’re on a private or domain network
- Finally give it a name.
Step 4: The very last step … run Visual Studio as administrator. Not doing so will not allow IIS Express to accept connections coming in on the IP address.
That’s all there is to it … now you’ll be able to debug your web apps / services within Visual Studio, serve them from IIS Express, but invoke them from a computer or device on the same network. Pretty slick.
Summary
Step 0: Enable bridged networking (if Windows is virtualized).
Step 1: Find IP address.
Step 2: Find IIS Express’s applicationhost.config file and update the binding info for your web app.
Step 3: Open a port on the firewall.
Step 4: Run Visual Studio as admin.
Step 5: Find and fix bugs … not that we’ll have any, because we’re all Professional Software Developers here.