I don't know about you, but I've had an utter nightmare trying to debug .NET 2.0 web applications across domains. Despite literally every trick in the book (such as creating local users with same username/password) I just could not get breakpoints to be hit. Using native (no auth) debugging, I could attach to the worker processes but symbols just were not loaded, no matter what I did.

It was when I found myself in the depths of dcomcnfg mucking around that I eventually decided that there must be an easier way. Then it hit me. I'd been so busy trying to go across domains (I could not change the domain of my dev machine or the server) that I didn't think about virtualising a development box.

One quick XP Pro build later on a Virtual PC, and one rather tedious VS.NET 2005 SP1 install (allocate at least 512Mb RAM - trust me) and I could hook that onto the same domain as my dev server.

Works a treat - but here's a tip that I haven't found elsewhere. Despite the fact that the debugger runs as a service, I found that I had to run the debugger monitor in order for VS2005 to ge able to connect. No idea why - doesn't seem logical. The other issue is that the debugger monitor has to start a named server that matches the name you're connecting with. You could run a term services session to the server logged in as your domain account, but lets face it, thats a pain. Also, you could only connect a couple of people before hitting your term services session limit, which means you'd be limited as to how many people could connect at once.

Thankfully, you can name the debugging 'server' you want to start. So... you can log onto the server as, say, a domain admin, then start up multiple remote debugger monitors. In each, go to Tools -> Options and set the Server Name. I found the syntax had to be DOMAIN\user@server-machine-name, e.g. BUSINESSDECISION\danmatthews@WEBDEV01.

Remember to close your term services session by disconnecting, not logging out. That way, your monitors keep running.

Remote debugging can be a pain but using this virtualisation technique I just sidestepped all the nasty pitfalls and went the simplest route possible. If you can run a dev image on VPC maybe it can work for you too. Good luck!