modelrail.otenko Trains, computers, vintage, retro, model railways… the lot…

net.tcp and IIS Express does not work

I've just spent time trying to rig up a test to get a working net.tcp server. Turns out that, in Visual Studio 2012 (and just about every other VS version), the IIS Express Server that one usually debugs through CANNOT support anything other than HTTPS and HTTP.

Q: Does IIS Express support non-HTTP protocols such as net.tcp or MSMQ?
A: No. IIS Express only supports HTTP and HTTPS as its protocol.

Please do not waste your time... When you hit debug on your net.tcp service, IIS Express will instantiate and you'll be thrown to your favourite web browser, staring at your root folder which is readable. You'll note that you'll also be on a port that has nothing to do with your web.config. This is because IIS Express has generated a random port and not cared one iota for your port configurations in web.config. You'll get nothing but connection refused when you try to connect to net.tcp://localhost:PORT/Service.

I was about to whinge that this tutorial on configuring a net.tcp service on IIS7 doesn't mention anything about incompatibilities with IIS Express. I suppose that one must assume by the header that the article is only for IIS7. A footnote would still be greatly appreciated for those trying to develop their code before deploying it!

If you ever want to get this to work, deploy and test your server on a real IIS instance and run from there... IIS7 preferably.

Note, if you need to debug... bring the server up, hit it with a simple query to make sure the app pool is active, and use Debug -> Attach to Process from Visual Studio. You'll find w3wp.exe way down the list with your Website's 'name' next to it. Highlight it and hit Attach to debug pesky server-side problems.

Once debugging in Visual Studio, you'll then need to open your source files (they can be in any folder, VS initially wont find them automatically) to set breakpoints. Note that exceptions will be caught in VS whilst debugging and will halt execution on IIS for all users. I have, once or twice, accidentally left the debugger attached overnight and had very angry clients in the morning with stalled connections.