Wednesday, February 18, 2009

Remote debugging

Yesterday I had quite a bit of fun trying to get remote debugging of a web application working.

I did solve this problem a little (very short) while ago… but I forgot what I had done.

So after executing a couple (quite a few) iterations of a Modify, Compile, Deploy, TryToDebug, Uninstall loop I know what you have to do to get it working. At least if you are using a deployment project to put the files up on the server.

You have to add the debug output from any project that you want to debug into to the deployment project*.

You must make sure that those debug outputs are in the right directory in the File System configuration pane so that the TargetName will have the files going into the correct directory on the server**.

Then you can install and debug. The setup of the remote debugger is a bit complex too. Basically the way I got it to work was by adding my own domain user (I log into my machine by logging into the domain) to the Administrators group on the server, and then logged in (via mstsc /console) to the server as myself (so that user could reconnect back to my machine). Bingo.


* You can’t just copy them up to the server it seems. I don’t know what the difference is, but it just does not manage to find them. I have even tried loading the symbols from the modules window directly – if complains that the symbols are not for the same version of the dll. I have not seen what happens if you are not actually deploying with an msi – there could be trouble. It is just one of those cases where there is some mechanism there that is storing some information somewhere and when it works everything is rosy, but when it does not work it can be fairly opaque. I guess that is what comes from not technically knowing what you are doing, but we can’t all be experts on the internal workings of everything – there is just not time, and when most of the time it just automagically works there is not much point either.

** The target name for the debug output of some project types (e.g. ASP.Net Web Application) will be bin/AssemblyName.pdb so the output needs to be placed in the Web Application Folder (where they seem to go by default), whereas other types (e.g. Class Library) will just be AssemblyName.pdb so their output needs to be put into the bin folder – they won’t be there by default, they will be one level up in the Web Application Folder. If you do not get this right the debug symbols will fail to load. You can look at information about what is being loaded from where in the Modules window found in Debug > Windows > Modules when you are in debug mode.

No comments:

Post a Comment