View Debug Statements Remotely from an ASP.NET application

Posted by: Malcolm Sheridan , on 6/24/2009, in Category ASP.NET
Views: 37224
Abstract: The following article demonstrates how to remotely view debug statements from an ASP.NET application using DebugView from Sysinternals.
View Debug Statements Remotely from an ASP.NET application
I recently did an article on how to use the System.Diagnostics.ConditionalAttribute class in conjunction with Conditional Compilation Symbols in ASP.NET - Compiling Conditional Code into ASP.NET Websites. I thought a good follow up article would be how to utilise Microsoft’s Sysinternals DebugView application to remotely view debug statements from an ASP.NET application. DebugView is an application that lets you monitor debug output on your local computer or any other computer that you can reach via TCP/IP. DebugView can be downloaded from here. No installation is required. Just run the executable.
One class that I use frequently when developing ASP.NET applications is the System.Diagnostics. Debug class. This class provides methods and properties that can help debug your code. One method in the Debug class is WriteLineWriteLine writes a specified message following by a line terminator to the debugger. You would normally see this information inside of Visual Studio by using the Output Window under View > Output in the menu:
The output window displays the debug statements which is handy when you’re debugging your code. But this window is only available when you’re using Visual Studio. Capturing this information on a remote ASP.NET application is possible by using DebugView to view the debug statements.
To begin with open Visual Studio 2008 and choose File > New > Web > ASP.NET Web Application. 
By default Visual Studio creates a Default.aspx file. Open the code behind and add the following code to the page load event:
protected void Page_Load(object sender, EventArgs e)
   Debug.WriteLine("This is only debug code " + DateTime.Now.ToString());
Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs)
   Debug.WriteLine("This is only debug code " & DateTime.Now.ToString())
End Sub
The Debug.WriteLine method will output debug statements which can be displayed by using DebugView. You should use this method in your code whenever you need to check a value in your code, or perhaps a piece of functionality that is vital to the entire application. Now to the fun part! To begin with open DebugView. From the menu choose Options > Always on Top. This ensures that when the website is running you’ll always be able to see the debug statements. The last thing left to do is run the project.   In DebugView you’ll see the debug statements being output from the website:
For this example I am running the ASP.NET application locally. But this will work if you connect to a remote ASP.NET application via TCP/IP, which makes this a great tool if you need to view debug information from a remote website. This code can also be used to view debug statements from a Silverlight application. Pretty cool huh?!
Trying to figure out what your code is doing on a web server is sometimes tricky to say the least. But with the help of DebugView, you can view your debug statements and figure out more easily why your code isn’t working as expected.
The entire source code of this application can be downloaded from here.

This article has been editorially reviewed by Suprotim Agarwal.

Absolutely Awesome Book on C# and .NET

C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.

We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).

Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.

Click here to Explore the Table of Contents or Download Sample Chapters!

What Others Are Reading!
Was this article worth reading? Share it with fellow developers too. Thanks!
Share on LinkedIn
Share on Google+

Malcolm Sheridan is a Microsoft awarded MVP in ASP.NET, a Telerik Insider and a regular presenter at conferences and user groups throughout Australia and New Zealand. Being an ASP.NET guy, his focus is on web technologies and has been for the past 10 years. He loves working with ASP.NET MVC these days and also loves getting his hands dirty with jQuery and JavaScript. He also writes technical articles on ASP.NET for SitePoint and other various websites. Follow him on twitter @malcolmsheridan

Page copy protected against web site content infringement 	by Copyscape

Feedback - Leave us some adulation, criticism and everything in between!
Comment posted by Marc B. on Thursday, June 25, 2009 3:48 AM
Wow, that sounds really cool! All our problems have to be debugged by dialing in to the customers network via VPN-VPN-Remote-Remote and there analysing DB- or FileLogs, more or less only knowing by some experience what could be the reason for error. My question about Debug.WriteLine is performance: how does writing out debug lines into space (where are they buffered ?) affect the overall performance of the site ? Would You recommend using it in production ? Thanks a lot for Your supportive articles! Kind regards from Vienna,Austria, Marc B.
Comment posted by Malcolm Sheridan on Thursday, June 25, 2009 7:51 PM
@Marc B
Thanks for the comments.  With this code comes a slight hit in performance so I wouldn'r recommend putting this into a production system.  If you compile your code as a debug build, it also compiles debug symbols into your assembly, which doesn't perform as well as a release build.  But if you're deploying to a dev or test site, by all means compile as a debug build and out your debug statements in your code to help you.
Comment posted by ATippett on Monday, June 29, 2009 1:24 PM
System.Diagnostic trace messages are indeed very useful, however you cannot simply view them remotely using DebugView **unless** DebugView is also running on the remote server (i.e. where the app being monitored is) in "client" mode. As an alternative you may want to consider using the Log4Net framework (google it) as this offers a high level of flexibilty both in terms of what information can be output but also where your output should go (including System.Diagnostic trace).
Comment posted by Malcolm Sheridan on Monday, June 29, 2009 8:17 PM
I use this debugging technique at my company all the time and I don't have DebugView installed on the remote web server.  If you have trouble setting this up send me an email.
Comment posted by A Tippett on Friday, July 3, 2009 3:13 PM
Thanks Malcom for clarifying my mistake (via email). Your article is indeed correct, it was my mistake for mis-reading Debug.WriteLine (which you quote) for Trace.WriteLine (which is the mechanism I use). Doh!
Comment posted by Checker on Tuesday, July 21, 2009 7:15 AM
What exactly is the point?
What is the difference between DebugView attached to another computer and using Remote Desktop then Debug view on the remote machine?
Comment posted by Malcolm Sheridan on Monday, August 3, 2009 7:25 PM
This is just an article explaining this can be done.  What happens if the machine has remote desktop disabled?  
Comment posted by paragyte on Monday, June 28, 2010 7:44 AM
Can any body give solution on What happens if the machine has remote desktop disabled?  
Comment posted by Duy Nguyen on Monday, July 23, 2012 1:54 PM
Can you get this to work with .NET 4.0 web apps?
Comment posted by abc on Friday, November 28, 2014 7:44 AM