Developing iPhone-optimized portions of an ASP.NET website presents a challenge. More specifically, it’s testing your creations that can be difficult.

Apple’s iPhone emulator only runs on Macs and the Windows-based alternatives don’t emulate mobile Safari well. That leaves us using an actual device as the only high-fidelity option for testing. That’s not all bad; especially when it comes to a touch-driven interface, testing with the real thing is preferable.

Unfortunately, the ASP.NET Development Server bundled with Visual Studio is severely restricted when it comes to testing externally. In fact, it could hardly be more restrictive – it refuses all external connections, even if those connections originate from the same local subnet.

In this post, I’m going to show you one way I’ve found to circumvent that restriction, how to configure your iPhone to take advantage of that, and how to connect to the development server once those steps are completed.

Note: This post specifically describes configuring an iPhone, but the same approach will work for any mobile device that supports using an HTTP proxy.

Fooling the ASP.NET Development Server

The fundamental problem is that Visual Studio’s ASP.NET Development Server actively refuses external connections. That’s a logical precaution if you’re in the business of selling web server operating systems, but it adds unnecessary friction to the legitimate endeavor of testing with mobile devices.

The solution that I stumbled onto uses a tool that you may already have installed: Fiddler. If you aren’t familiar with Fiddler, this recording of Eric Lawrence’s session at MIX10 is a great way to learn a lot about Fiddler in relatively little time.

The feature that we’re specifically interested in is its HTTP proxy server. Unlike the ASP.NET Development Server, Fiddler does not restrict connections from external devices. Even better, routing an external device’s connections through Fiddler is misdirection enough to fool the development server into accepting them.

Checking Fiddler’s proxy port

With Fiddler installed, the first step is to determine which port it’s running the proxy server on. On fresh installs, the default setting is port 8888.

If you’ve had Fiddler installed a while, it doesn’t hurt to double check the setting. You can do that in Fiddler by navigating to Tools > Fiddler Options, and selecting the Connections tab:

While you have that dialog open, also verify that the three checkboxes circled above are checked.

Finding your IP address

The next step is to determine your machine’s IP address on the local network. A quick way to do that is running ipconfig at the command prompt.

To open a command prompt, press Win + R, type cmd in the field, and hit enter.

At the command prompt that opens, type ipconfig and hit enter.

What you’re looking for here is the IPv4 address for your machine’s primary network adapter. “Local Area Connection” is mine, so I need to use 192.168.1.119 to connect to my machine. A wireless connection is fine too, as long as it’s connected to the same access point that the iPhone is.

Find yours and make note of it for the next step.

Note: This must be an IP address that your iPhone can route to while connected via Wi-Fi. In most business and almost all residential networks, you won’t need to give this much thought. However, if you’re working within a more complex corporate network and can’t get your iPhone to connect to Fiddler’s proxy server, you may need help from a system administrator.

Configuring an iPhone to route through Fiddler

With your development machine’s IP address and Fiddler’s port number in hand, you’re ready to configure your iPhone to channel its network traffic through Fiddler’s proxy server.

To do that, open the settings app and tap the Wi-Fi option (below, left).

In the Wi-Fi Networks panel (above, right), you’ll see the wireless networks that your iPhone has detected in range. Tap the arrow at the right side of the Wi-Fi connection that you intend to use for testing.

At the very bottom of the panel that opens (left), find the HTTP Proxy setting and tap Manual (1) to enable the feature. In the fields that appear, enter your computer’s local IP address for the server (2), and the port that Fiddler is listening on for the… Port (3).

That’s it! Your iPhone is configured to route its traffic through an instance of Fiddler running on your development machine.

Starting the development server

Now that you have a conduit from your iPhone to the development server, it’s time to get the development server running by starting your site in Visual Studio. Anything that starts an instance of the development server will do (e.g. Start Without Debugging or View in Browser).

Make note of the URL displayed in your browser when Visual Studio displays your website. We’ll modify that slightly in the next step and use it to access the development server from Mobile Safari.

If the development server is already running, you can also determine its address by right-clicking its icon in the system tray and choosing “Show Details”. That will present you with a window that looks like this:

The “Root URL” address there is what you’ll need in the final step.

Accessing the development server from your device

Finally, we’re ready to start testing against the development server from the browser on a mobile device. The one minor issue remaining is that the exact URL advertised by the development server won’t work in this setup.

To make Fiddler happy, you need to append a trailing period to the hostname portion of the address. For instance, this “Root URL” advertised in the example above will not work without modification:

Wrong!

http://localhost:24833/WebSite1

To make it work, we simply need to append the trailing period to localhost:

http://localhost.:24833/WebSite1

That does look odd, but it works.

Fiddler also recognizes ipv4.fiddler as an alias for the localhost loopback, which is a little bit more intuitive. So, you could also access the same example with this address if you prefer:

http://ipv4.fiddler:24833/WebSite1

That’s it. You’re armed and ready to test with any external device on your local network now, so long as it supports routing its traffic through an HTTP proxy.

Conclusion

At first, this may seem like many steps and a lot of work. Don’t worry. Once you go through the motions a few times, you’ll find that it’s a breeze.

It’s especially smooth sailing in future repetitions, since your machine’s local IP probably won’t change often, and Fiddler’s proxy IP won’t change at all.

Of course, Fiddler isn’t the only utility that will work as an intermediary like this, but using Fiddler brings the great side-effect of providing HTTP traffic analysis while you’re testing. That added utility is welcome when you’re testing on a mobile device where the on-device development tools are basically nonexistent.