A brief, incomplete definition of 'an engineer'

Most of us, much of the time, react to "You're wrong" with "No I'm not! And you can't tell me otherwise!" An engineer's response is "How? Show me."

Thinking outside the box with the ASP.Net Development Server

A well-known limitation of the ASP.Net Development Server is that it will only bind to the local interface of the development machine, never the LAN interface, and so you can't bring up pages served from the development server from anywhere but on the box itself via the localhost name or 127.0.0.1 address. And fair enough, it's meant to be a debugger aid, not a web server. But there are situations where you want to think outside that box, and fortunately, it's dead easy to do so.

I wanted to do that because I'm working on a project where the server-side code is C# assemblies and the client-side is pure HTML, CSS, and JavaScript (no server controls or other ASP.Net-isms). I wanted to use VS.Net for debugging server-side C# code, and Chrome's Dev Tools or Firebug for debugging the client-side code in the browser. VS.Net makes it remarkably easy to debug server-side code — just mark the "project" with the client code as the startup project, chooose a port if you want, set the virtual path, make sure the server-side assembly projects are in the solution, and hit F5 (or click Run). It fires up the ASP.Net Development Server and you have full debugging of the server-side code (and client-side code as well, if you like, with its integration with IE). Excellent, couldn't be much easier. But for me, this is all happening in a VM (this is for a client, and I keep all my client stuff isolated from my work and each other using VMs) but I'd like to do the client-side debugging with Chrome's Dev Tools on my main machine.

It was only a mild irritation (I can run a browser in the VM happily enough), so I didn't want to spend any time on it, but I figured this has to be one of the simplest examples of the need for port forwarding or proxy serving on the planet (just bridging interfaces), and so I did a quick web search and found this article about using Squid to do it. Now, Squid is a big hammer for this nail, but it's so easy to set up, that it's still reasonable to use it.

That article's good, but I thought a few things weren't as clear as they may have been, so here's my step-by-step:

1. Tell the ASP.Net Development Server to use a particular port rather than picking one at random:
   1. Click the client code project in your solution
   2. Look at the properties
   3. Make sure that Use dynamic ports is False
   4. Choose your port under Port number (if you just turned off the Use dynamic ports option, you may have to click away from the properties and click back again to unlock the field; minor bug in VS.Net)
   I'll call that the "internal" port (the one that only works within the VM). In my case, I used 80; the VM doesn't serve any other web content.
2. Be sure your dev machine's firewall allows incoming connections whatever external port you're going to use.
3. Get and install Squid. The quick-and-easy thing is to get a binary from these nice people who are kind enough to maintain a Windows port built using the Microsoft toolchain: Just scroll down under the features list and click the "Squid download Page" link. Or, of course, you could grab the source and do it yourself (with the MS toolchain, or Cygwin and GCC). I grabbed 2.7.STABLE8 from the the nice people.
4. Unzip it somewhere handy. The Windows binary assumes C:\Squid, so I went with the path of least resistance and put it there.
5. Install it as a service:
   1. Open a command prompt (as Administrator, if you're on Windows 7 or similar)
   2. Change to C:\Squid\sbin.
   3. Type squid -i -n Squid
6. Set up the default config: Using your favorite file browser:
   1. Go to C:\Squid\etc
   2. Copy squid.conf.default as squid.conf
   3. Copy mime.conf.default as mime.conf (we're not going to edit it, but it's required)
7. Set up the proxying:
   1. Open squid.conf with your favorite text editor
   2. Go to the very end of the file
   3. Paste this in, replacing the bits in curly braces with your own values (without the curly braces) (mind the word-wrapping, Blogger is giving me a hard time yet again; best to copy and paste):

      http_port {EXTERNAL_PORT} accel defaultsite={EXTERNAL_IP_ADDRESS}
      cache_peer localhost parent {INTERNAL_PORT} 0 no-query originserver name=myAccel
      
      acl our_sites dstdomain {EXTERNAL_IP_ADDRESS}
      http_access allow our_sites
      cache_peer_access myAccel allow our_sites
      cache_peer_access myAccel deny all

      So in my case, since I want both the internal and external ports to be 80 and my VM's external (LAN) IP is 192.168.142.153, it's

      http_port 80 accel defaultsite=192.168.142.153
      cache_peer localhost parent 80 0 no-query originserver name=myAccel
      acl our_sites dstdomain 192.168.142.153
      http_access allow our_sites
      cache_peer_access myAccel allow our_sites
      cache_peer_access myAccel deny all

      ...but if you use different internal and external ports, be sure to set them according to the placeholders in the above.
   4. Save the file
8. In your (Administrator) command window, tell Squid to validate the config:
   squid -z
   You should see the message Creating Swap Directories and pretty much nothing else.
9. Start the service:
   net start Squid
10. You might choose to have Squid start when you boot the machine, via the usual services.msc settings

Sorted!