WinForms FAQ - Debugging

You have the regular #if and #else preprocessor directive inside which you could place your code. Take a look at the ‘C# Preprocessor Directives’ section for the complete list of preprocessor directives.

There is also a concept of ‘Conditonal Methods’ that will let you declare some methods as conditional methods based on the presence of certain preprocessor directives, using the ConditionalAttribute. Then the compiler will not only ignore the method, but also the method-call if the preprocessor symbol is not defined. Take a look at this MSDN section for more information:

Conditional Methods Tutorial

Using dual monitors is one way to tackle this problem, but If you happen to be running on a terminal server machine there’s an even better way to do this. Create a terminal server session to your own machine and start the exe in the terminal server window. Start the debugger on the console window and attach it to the exe in the other session. This is helpful if you’re debugging paint/focus issues because then the debugger won’t steal focus from your app when a breakpoint gets hit.

(from sburke_online@microsoft..nospam..com on microsoft.public.dotnet.framework.windowsforms)

1) In VS.NET go to the Debug Menu >> 'Exceptions...' >> 'Common Language Runtime Exceptions' >> 'System'  and select 'System.NullReferenceException' 
 
2)  In the bottom of that dialog there is a 'When the exception is thrown:' group box, select 'Break into the debugger' 

3) Run your scenario.   When the exception is thrown, the debugger will stop and notify you with a dialog that says something like: 
  		'An exception of type 'System.NullReferenceException' has been thrown.
		[Break] [Continue]'

Hit [Break].   This will put you on the line of code that’s causing the problem.

(from sburke_online@microsoft..nospam..com on microsoft.public.dotnet.framework.windowsforms)

You can use the Console.Write and Console.WriteLine methods from within a Windows Forms project to do this. The class DefaultTraceListener is used to implement this functionality.
When your application is launched from the VS.NET IDE in Debug mode, you will see all trace and debug messages in the Output window by calling:

System.Diagnostics.Trace.WriteLine()
or
System.Diagnostics.Debug.WriteLine()

When your application is launched from the VS.NET IDE in Debug mode, you will see all trace and debug messages in the Output window calling:

Yes, there are framework classes that will give you the Call Stack information at a particular point.

[C#]
		public static void TraceExceptionCatched(Exception e)
		{
			StackTrace st = new StackTrace(1, true);
			StackFrame sf = st.GetFrame(StackTrace.METHODS_TO_SKIP);
			if (sf != null)
			{
				MethodBase mb = sf.GetMethod();
				Trace.WriteLine(e.ToString());
				StringBuilder sb = new StringBuilder();
				sb.Append('catched in File ');
				sb.Append(sf.GetFileName());
				sb.Append(', line ');
				sb.Append(sf.GetFileLineNumber());
				Trace.WriteLine(sb.ToString());
				sb = new StringBuilder();
				sb.Append('in method ');
				sb.Append(mb.ReflectedType.Name);
				sb.Append('.');
				sb.Append(mb.Name);
				sb.Append('(');
				bool first = true;
				foreach (ParameterInfo pi in mb.GetParameters())
				{
					if (!first)
						sb.Append(', ');
					first = false;
					sb.Append(pi.ParameterType.Name);
					sb.Append(' ');
					sb.Append(pi.Name);
				}   
				sb.Append(');');
				Trace.WriteLine(sb.ToString());
			}
		}

You could then call this method from the Catch portion of a try/catch block.

Yes, there are classes in the framework that will provide you call stack information that you can trace to the output:

[C#]
		public static void TraceCallStack()
		{
			StackTrace st = new StackTrace(1, true);
			StackFrame sf = st.GetFrame(StackTrace.METHODS_TO_SKIP);
			if (sf != null)
			{
				MethodBase mb = sf.GetMethod();
				StringBuilder sb = new StringBuilder();
				sb.Append(mb.ReflectedType.Name);
				sb.Append('.');
				sb.Append(mb.Name);
				sb.Append('(');
				bool first = true;
				foreach (ParameterInfo pi in mb.GetParameters())
				{
					if (!first)
						sb.Append(', ');
					first = false;
					sb.Append(pi.ParameterType.Name);
					sb.Append(' ');
					sb.Append(pi.Name);
				}   
				sb.Append(');');

				int n = StackTrace.METHODS_TO_SKIP+1;
				sf = st.GetFrame(n);
				if (sf != null)
				{
					sb.Append(' called from ');

					do 
					{
						mb = sf.GetMethod();
						sb.Append(mb.ReflectedType.Name);
						sb.Append('.');
						sb.Append(mb.Name);
						sb.Append(':');
						sf = st.GetFrame(++n);
					}
					while (sf != null);
                        
				}

				Trace.WriteLine(sb.ToString());
			}
		}

You need to add a Trace Listener to your code. Below is sample code that adds a TextWriterTraceListener (and don’t forget the Flush before you terminate). For more information on tracing in general, look for the topic ‘Tracing Code in an Application’ in your online .NET documentation.

	//set up the listener...
	System.IO.FileStream myTraceLog = new  System.IO.FileStream(@'C:\myTraceLog.txt',  System.IO.FileMode.OpenOrCreate);
	TextWriterTraceListener myListener = new TextWriterTraceListener(myTraceLog);
	..........
	//output to the instance of your listener
	myListener.WriteLine( 'This is some good stuff');
	...........
	//flush any open output before termination... maybe in an override of your form’s OnClosed
	myListener.Flush();

This is possible if the same listener was added more than once to the Listeners list in Trace. This is possible even if an assembly that you linked do makes an additional entry for the same listener.

Perform a check like this before adding a listener.

	if(Trace.Listeners.Count == 0)
	{
		Trace.Listeners.Add(new TextWriterTraceListener(Console.Out));
		Trace.AutoFlush = true;
		Trace.Indent();
	}

You need to use a second instance of VS.NET to debug the one that’s running
the code.

	1) Put your control on a form in VS.NET
	2) Start a 2nd Vs.Net
	3) Choose the Debug menu >> Processes ...
	4) Double click 'devenv.exe' and choose 'Common Language Runtime' as the types
of debugging
	5) Open your code file, set your breakpoint, and you’re debugging.

(from sburke_online@microsoft..nospam..com on microsoft.public.dotnet.framework.windowsforms)

When the system fails to locate an assembly, it generates a log file. Fuslogvw.exe is the viewer program that gives you access to this log. You can run this tool from a command line. This log information helps you diagnose why the .NET Framework cannot locate an assembly at run time.