Accessing your Windows Development Environment from OSX

DoneDone is built using ASP.NET, meaning our development environment is Visual Studio on Windows. Ka Wai and I both use MacBook Pros with Parallels installed because it gives us easy access to all major browsers on OSX and Windows.

One challenge I ran into when I first joined DoneDone (now 3 years ago!) was the difficulty in accessing my local Windows development environment from OSX. After some trial and error, I arrived at a solution that’s been working well for me, and wanted to share the setup process.

Two Separate Machines, One Local Network

Much like the Vatican exists as an independent state within Rome, our Windows virtual machine serves as our holy seat of power within the unclean OSX environment (I kid, I kid). Although both OS’s live on the same hardware, you can think of them as two separate machines connected by a local network. If you ping localhost from your OSX Terminal, you’ll receive a response from your OSX instance. If you ping localhost from your Windows Command Prompt in Parallels, you’ll receive a response from your Windows instance.

So our goal is to allow traffic to freely flow like so:

OSX Web Browser <-> Parallels <-> Windows VM <-> Development Web Server

Visual Studio Development Server Options

By default, Visual Studio web projects use a built-in development web server. Whenever you run or debug your web project in VS, the dev server spins up and makes your site available on a localhost port, such as http://localhost:54321. My original goal was to expose this port to my OSX environment, but soon discovered that this is simply not possible – the VS dev server is only accessible by the local Windows environment. External requests, even from the OSX host machine, are always blocked.

caption

Here’s our sample application running on the built-in VS dev server – notice the localhost URL.

Luckily, Visual Studio gives you the option to choose a different development web server. Right-click on your web project in the Solution Explorer and choose Properties, then select the Web tab. You’ll see 3 options in the Servers section:

  • Use Visual Studio Development Server – This is the default option, but it only allows traffic from the local Windows machine.
  • Use Local IIS Web Server – This allows us to use either IIS or IIS Express, which must be installed on our local machine.
  • Use Custom Web Server – This allows us to use another custom server URL.

Adding an IIS Site for your Project

We want to use the second option – Use Local IIS Web Server – but which version of IIS should we select? Since IIS Express only allows sites to be created using localhost URLs, it won’t work for our purposes. If you try to connect to http://localhost from within OSX, you’ll simply be connecting to your OSX machine. We’ll instead need to use the full-fledged version of IIS, which can be installed under Control Panel > Programs > Turn Windows features on or off > Internet Information Services.

Once IIS is installed, we need to create a new IIS site to use with our Visual Studio project. Open IIS Manager, right-click on Sites in the sidebar, then choose Add Web Site.

Enter the name of your project as the Site Name, then choose the project’s root directory (the directory that holds your web.config file) in the Physical Path field. Finally, in the Host name field, enter the URL you want to use to access the project. I’m using aspnetsite.local for this example, but this can be pretty much anything except localhost.

my caption

Our IIS Site settings

Click OK to create your new site.

Note: make sure your IIS site’s Application Pool is set to the same .NET Framework version as your Visual Studio project, and the Application Pool user has permission to your project’s directory. Otherwise, you’ll receive an IIS error when attempting to access your site.

Adding your Project URL to the Windows Hosts file

Unfortunately, Windows doesn’t know how to interpret our custom http://aspnetsite.local URL, since it doesn’t resolve to an IP address. We can correct this by adding an entry in the Windows hosts file. Navigate to C:\Windows\System32\drivers\etc and copy the file named hosts to your desktop. Edit the hosts file in a text editor, and add this line to the bottom:

127.0.0.1      aspnetsite.local

Now copy the hosts file from your desktop back into C:\Windows\System32\drivers\etc, and confirm that you want to overwrite the file. The entry you added tells Windows to map your custom URL to your local IP address. Now when you visit http://aspnetsite.local within Windows, it will send the request to your local 127.0.0.1 IP address. Since your IIS site is listening for requests for that hostname on your local IP, it will respond to the request.

Using IIS with your Visual Studio Project

Now we need to configure our Visual Studio project to use the IIS site. Since VS will need to interact with IIS, you’ll need to run Visual Studio as an Administrator. Right-click the VS icon and choose Run as Administrator, then return to your project’s Properties.

Choose Use Local IIS Web Server and uncheck Use IIS Express. Enter http://aspnetsite.local (or the value you used for the IIS site’s host name) in the Project Url field, then save your settings.

caption

Make sure the Project Url matches your IIS Site host name.

Now run your project:

caption

Our Visual Studio Project is now running on our custom URL.

Voilà! Visual Studio is now using IIS to serve up our project. Everything will work exactly as if you were using the built-in dev server, including the debugger and breakpoints. But, we can now allow external traffic to access our website, including our OSX environment.

Allowing Traffic through Windows Firewall

We want to accept incoming requests from OSX, but we don’t want to allow any other traffic for security reasons. If you’re using Windows Firewall, open it and navigate to Inbound Rules, then locate the rules for World Wide Web Services (HTTP Traffic-In). These rules should have been installed along with IIS. There should be 2 WWW rules – one for your Domain/Private profile, and one for Public. Make sure the Domain/Private rule is enabled.

If you’re using another firewall program, you’ll need to add a similar rule that allows local traffic through TCP port 80.

Adding your Project URL to the OSX Hosts file

At this point, our project is running on a custom url (https://aspnetsite.local) and everything works great within Windows. But, OSX doesn’t know which IP this address resolves to. We corrected this problem on the Windows side, so now let’s do the same for OSX.

Locate the IPv4 address of your Windows machine, either by viewing the details of your LAN connection or by entering ipconfig/all in the Command Prompt. Once you have your IP address (mine was 192.168.1.76), switch back to OSX and enter the following in a Terminal window:

sudo nano /private/etc hosts

Enter your administrator password, and your OSX hosts file will open in the nano editor. Use your keyboard down arrow to scroll to the end of the file, then add a new line at the bottom:

192.168.1.76      aspnetsite.local

Be sure to use the Windows IP address you just retrieved as the left value, and your project’s custom host name as the right value.

Once entered, press Ctrl+O, then Enter, then Ctrl+X. This saves the file and exits the editor. Now open your OSX web browser of choice and navigate to http://aspnetsite.local.

OSX

OSX is successfully talking to Windows.

And we’re done! You can now access your Visual Studio project from any Mac browser (including Xcode’s iOS Simulator for mobile browser testing), with full support for debugging.

Here’s a recap of the steps we took to accomplish this:

  • Install IIS
  • Create a new IIS Site that points to the local directory of our VS project
  • Add our IIS Site host name to the Windows hosts file
  • Run Visual Studio as an Administrator
  • Update the VS Project settings to use our IIS Site URL
  • Allow local incoming traffic through Windows Firewall
  • Add an OSX hosts file entry using our Windows IP address and our IIS Site host name

Jeremy Kratz is a developer at DoneDone. Follow him on Twitter via @jwkratz.