Like most BizTalk Server developers I am addicted to the use of DebugView. This, in case you are one of the three BizTalk developers out there who are still not aware of it, is a free utility written by the SysInternals people. Microsoft bought SysInternals a while back, and the utility can now be downloaded from their web site at:
http://www.microsoft.com/technet/sysinternals/utilities/debugview.mspx
DebugView provides a viewer for traces created using the Win32 OutputDebugString() API.You can liberally instrument your .NET code using calls to System.Diagnostics.Debug.Write<xxx> methods, then open up DebugView and run you code. The output is nicely displayed in the DebugView console.For BizTalk developers, this is an indispensable tool because there is no way to single-step through XLANG/s expressions. The Orchestration debugger is built on top of the orchestration engine, and is not a ‘true’ Win32 debugger. It can only single-step through interactions between the orchestration and the orchestration engine which occur at a much coarser level of granularity than individual lines of XLANG/s code.
I’ve spent the last couple of weeks pretending to be an ASP.NET 2.0 developer. The code I was writing does a fair amount of re-direction. It supports a number of different log-in models based on the Forms Authentication model in ASP.NET 2.0, but integrated with a remote identity provider. The code is ‘proof of concept’ stuff, and supports different ’candidate’ approaches, including the ability to switch to local authentication in order to demonstrate the code in scenarios where we have no remote connectivity. To begin with I (rather stupidly, in hindsight) was trying to develop using the new Web Site project type in Visual Studio. Oh dear. I needed to use SSL sessions to debug the code because we are using CardSpace. You can’t do this under the local web server. I tried, without success, to debug my code under IIS, but found that, for some reason, I was unable to attach to IIS worker processes! Then, I really came unstuck when ASP.NET completely lost the ability to debug. It was creating pdb files OK, but one of them appeared to be corrupted somehow each time it was built (for example, no version number), and Visual Studio insisted that I had no symbols loaded, even though the Module window clearly showed that I did!
I gave up, and ported the code over to a Web Application project. I still have problems. Visual Studio currently reports a set of spurious build errors ‘dynamically’ while using the designer (these change dynamically over time even if I don’t touch the keyboard – yes I mean it!I just sit there and stare at the screen for a minute or two and see the error messages change before my eyes), but then builds and publishes the application anyway. It has lost the ability to see Master Pages if I use generated paths with the ‘~’ specifier.It has also become hopelessly confused in regard to a custom control that I am using -a problem, incidentally, for which there are thousands of hits in Google, but only one conclusion – ‘tough – it’s a long-standing bug – you can’t fix it and there’s no known workaround – rebuild your project from scratch’. Apart from that, the Web Application works OK, and I can now debug my code smoothly under SSL sessions. A good lesson learned. I certainly won’t use Web Site projects in future, and will try not to use ASP.NET unless I have to, until such time as Microsoft sees fit to stabilise the design-time ASP.NET tools.
The point of this, apart from letting off steam about the general flakiness of ASP.NET 2.0 under Visual Studio 2005 SP1 (it’s horrible), is that while developing using the Web Site, I needed to use DebugView quite extensively. Even now, it is of some use due to the re-direction. I can trace my code in one page, even though this page redirects to another so that I can’t see my trace output using the built-in tracing features of ASP.NET. DebugView shows me what I need to see, as long as I remember to place ‘#define DEBUG’ statements in my ‘CodeBehind’ files.
I ran into a problem with DebugView which I have seen before. I’ve been trying to research it to come up with a definitive answer, but I don’t know the underlying cause – just the symptoms. My problem is that my ASP.NET code runs in a different session to the desktop. This means that the output does not appear in DebugView unless I enable the ‘Capture Global Win32’ option. However, this option was not available in DebugView.
At this point, I should say that I am developing on Windows Server 2003 R2. I run Vista on my notebook. When I open the same version of DebugView on my Vista notebook, I can see the ‘Capture Global Win32’ option. However, I can’t see it when I run DebugView on the Windows Server 2003 box.
I was tearing my hair out over this one, and it isn’t the first time I have run into this problem. I spent some time trying to find an answer on Google. I didn’t turn anything up, but somewhere I read something about remote connections. I had a thought. I powered up a Remote Desktop session to my own development box and then opened DebugView. Success! The ‘Capture Global Win32’ option appeared, and once selected, DebugView started happily displaying the output from my ASP.NET application.
This approach cannot be used on XP (or, I think, Vista) because, even with SP2, XP does not support concurrent remotedesktop sessions. Apparently, Microsoft was going to lift this restriction at some point, but then decided not to. As I say, when running DebugView under Vista, I don’t get the problem anyway.
I experimented further with DebugView by setting up a ‘client’ instance (surely this should be termed a ‘server’ instance’) and then connecting to this on the same machine. In my first attempt, this appeared to work, but when I tried to reproduce the approach the following day, it failed. The Remote Desktop approach works every time though.
As I say, I don’t currently have an explanation. I know, from Googling, that there are some interesting issues when using OutputDebugString regarding the permission set granted to an underlying Mutex. Maybe the behaviour of DebugView has something to do with this. Maybe the explanation is simpler. It may have something to do with having another registered debugger in the same Windows session. I’m not sure. What I do know is that remoting into your own desktop on Windows Server 2003 works very nicely indeed.