Irrelevant musings about software development

After much time, trial and error, I was finally able to get Visual Studio's remote debugging features to work.  In my travels around the Internet, no one seems to have compiled all the steps to make the process work successfully and seemlessly into one page, this is my attempt.

Setting up

Complete all the steps listed on the How to: Set Up Remote Debugging article on MSDN.

Permissions

Don't try and fight the cross-domain permissions battle, its just not worth it.  If the machine your trying debug is not on a domain, then don't run VS from a machine thats on the domain. Make sure the same user with the same password exists on both machines.

PDB's

Put the PDB files on the remote machine (target) in the same folder as your app.

Source Code

In our environment, our build server produces an installer, and it also produces the PDB's we used in the above step. If we want Visual Studio to automatically pick up the right source files when we are debugging, you need to store the source code on your host machine in the same location as the machine that built your PDB's.

For example, in our world, on our build server the code lives on d:\code\projectname\code\ so on your host machine, you would store our source code on d:\code\projectname\code

Results

If you have followed all these steps, and if the stars align just right, you should now be able to step through your source code when remote debugging.

Questions/Comments

Questions, comments or just can't make it work for some reason? Leave a comment and fill out your actual email address nd I'll try to address it!

I've been using VMware in production for two years now.  During that time, I've been thrilled with it.  I run my mail server and my web server on my host OS without any problems.  About 2 months ago, I upgraded the hardware on my server from a recycled desktop PC to a dual core box.

Since I the machine now had two physical CPU's, I figured I would set my VM's to have two processors in the VMware config.  I figured this way, each VM could use both CPU's as needed, and they could do there work faster, and there would be less latency when say IIS is starting up a new worker process, or the CLR is JIT'ing my blog.

Did I notice a speed improvement, very hard to say.  I did notice that things like browsing around in Windows Explorer seemed very very laggy.

So I decided to make a maintenance window this afternoon and shutdown both VM's, and set there processor count back to 1 and see if that made a difference.  Boy did it ever!  Now the host CPU is mostly idle, the GUI on my web server is much more responsive, life is good.

I'm speculating that the reason the performance got a lot better when I switched the VM's to one CPU on a dual core machine has a lot to do with how VMware handles multiprocessor machines, and moving the tasks between CPU's, and the CPU's L1 and L2 cache, and cache hits.  But thats just wild speculation :)

I tried Windows Vista for a week, loved the new Explorer, loved the new visuals and animations, hated the crashes and Explorer would lock up a lot.

A while back, a few bloggers talked about how much faster and better Windows Server 2008 was than Windows Vista; so I figured I would give Server 2008 a shot.  A quick Google search turned up www.Win2008Workstation.com. I followed the guides on that site, and I now have a desktop which looks like Vista, but performs much faster, and I get MUCH fewer lockups of Windows Explorer.

I did have to set DEP to "Essential Windows programs and services only" otherwise some games and programs wouldn't install.  But other than that, its been a great experience! Way to go Windows Server 2008 team!