Visual Studio .NET - different techinique for debugging

Asked By aman on 20-Sep-11 04:53 AM
hi all,

what are the different techniques for debugging in .net?

thanks and regards
Aman Khan
smr replied to aman on 20-Sep-11 05:04 AM
HI

 just wanted to suggest with regards to this point that if you want to test webpages on different systems then you can use the newly released SuperPreview technology:

  • http://www.microsoft.com/downloads/details.aspx?FamilyID=8e6ac106-525d-45d0-84db-dccff3fae677&displaylang=en 
here is the information

refer the links below
http://lwn.net/images/pdf/LDD3/ch04.pdf
http://www.c-sharpcorner.com/UploadFile/mborromeo/DebugTechniques11212005001201AM/DebugTechniques.aspx
Reena Jain replied to aman on 20-Sep-11 05:04 AM
hi,

Debugging an ASP.NET Web application with Visual Studio .NET is similar to debugging a Windows Form or any other Windows application. The fact that application is running on the Web should be mostly transparent to you.

Further .NET debugging tools: Watch, Autos, Locals, Me, Immediate, and the Call Stack Windows

As you can see from this list you have a variety of other tools available to you as a VS.NET developer to analyse the program state at the breakpoint, as follows:

Watch

The Watch window allows you to add 'watches' to particularly variables and expression for continuous monitoring. Thus when you set up a watch whenever you return to the IDE while debugging you will see the current value of the variable or expression defined by the watch.

Autos

The autos window (automatically) displays the variables in the current statement and the previous statement.

Locals

Displays the variables local to the current context, i.e. the current method under execution

Me

The Me window allows you to examine members associated with the current object – typically a web form for an ASP.NET application, but not necessarily. It also allows you to change these values.

Immediate

The immediate window allows (immediate) access to the values of variables and expressions while debugging, at the breakpoint.

Call Stack

The Call Stack window shows you the method call stack thus providing information about the path taken by the code to reach its current point of execution.

Suchit shah replied to aman on 20-Sep-11 05:04 AM
  • Do you remember the last time when you fixed a small but trivial bug in your system, if you did then just try to remember how did you found the cause of the bugs ?????, which category the cause belongs to ??? (was it a functional error, typo error, coding error, null reference error or caching error), now how did you fixed the bug what steps you took to fix the bugs?????????.


    Truly speaking my experience, sometimes I got a bug in the system and searching the cause of the bug took more time than fixing the bug, because bug was simple typo/coding/null reference error. So guys be careful, these typo/syntactical/null reference errors….etc. category of bugs becomes more trivial and it takes a lot of time of developer. So now we should have some salutary lessons from our last small trivial bug, so that in future these issue will never come.


    Congratulations!!!! You are one of the few who realize that over 80% of errors are simple and easy to fix. It is important to realize this as it can save a lot of time. Time that could be wasted making unnecessary changes, that in turn can cause further problems.

    Programming is a humbling experience. An experience that causes one to reflect on human error. One major cause of these errors is syntax, syntax, syntax. We tend not to notice when we have made a typo. It is too easy to spend an hour trying to fix a problem that was caused by a typo. Accepting human error, that you made a mistake, is a reasonable first assumption.

    Another important assumption to fixing problems is Occam's razor - the simplest explanation is more often than not the best. When we initially expect a simple error we don't try to over complicate things and we are more likely to use basic techniques to trap the error; we use simple debugging procedures.

    Sometimes just writing a message is enough to see what is going on. One easy technique is to trap the error in a try catch block and write the error message. Its surprising how often this simple technique is not used.

    In asp.net there is a custom errors mode remote only. What this does is display the exception only on the local server, but anywhere else. Other users of your application may be directed to a customized error page, while you figure out what's going on.

    A very important step to avoiding errors in your application is testing. This is best done on a separate machine to the development and production servers. Even if you don't have access to a test environment this is no reason not to test. We developers are not the best testers -:) . Get someone else or preferably a group to test, believe me you'll save time and probably money.

    One of the most common errors is the 'object reference not set to an instance of an object'. Null reference errors are common too. Something, a reference or a parameter for example, is missing. So check the page references and parameters. Look in that error line to see what may be missing or null. Write any values that may be null.

    A simple thing that you can do is continue to practice. Programming in an unfamiliar language is slow to start with, but experience is cumulative. As you get more practice, things like error handling become easier. It doesn't become easier if you just copy & paste all the time, there is no substitute for understanding what's going on.

    There are many debugging techniques, but that is not the point of this article. Its not until I started to appreciate the number of my errors and the simplicity of fixing them, that I really started to make progress. At times I am still guilty of skipping the diagnosis and heading straight for the medicine cupboard. This has almost always been a mistake.

    I hope that you avoid some of the frustrations that I have had over the years by not ignoring human error and accepting how simple steps can resolve most problems.

    Happy Coding! Enjoy Coding!!!!!!!!!
  • http://forums.asp.net/members/rtpHarry.aspx

    http://forums.asp.net/members/rtpHarry.aspx

    All-Star

    55307 Points

    http://forums.asp.net/search?q=author%3A%28%22rtpHarry%22%29&s=postdate&d=desc

    • http://forums.asp.net/post/set/53/1415487/3118577
    •  

    Re: Quick and Simple Debugging Techniques

    Apr 25, 2009 06:26 PM | http://forums.asp.net/post/3118577.aspx

     Hi, nice article, you are totally correct with bug tracking - by far the longest amount of time is spent tracking down the problem. Usually takes longer than coding the feature and fixing the feature combined!


    nizam133

    A very important step to avoiding errors in your application is testing. This is best done on a separate machine to the development and production servers. Even if you don't have access to a test environment this is no reason not to test. We developers are not the best testers -:) . Get someone else or preferably a group to test, believe me you'll save time and probably money.
     

    I just wanted to suggest with regards to this point that if you want to test webpages on different systems then you can use the newly released SuperPreview technology:

    • http://www.microsoft.com/downloads/details.aspx?FamilyID=8e6ac106-525d-45d0-84db-dccff3fae677&displaylang=en 

    This lets you preview and debug sites in multiple browsers (I think the free version is IE only but you can test all sorts of browsers in the version that is included with Expression).

    Also microsoft has released free virtual pc images that will let you simulate a complete computer inside a virtual pc window. You can get windows xp and windows vista with a variety of browsers pre installed:

    • http://www.microsoft.com/downloads/details.aspx?FamilyId=21EABB90-958F-4B64-B5F1-73D0A413C8EF&displaylang=en 

    These images are actually due to expire in about 5 days but MS usually release more when this happens. The reason for this is that they are fully functioning versions of the operating system and they dont want you to be able to use it as your full operating system for free.



  • Debugging GUI applications for me mostly consists of printing out debug statements in the form of a dialog box with some text. While this technique was helpful for small to medium size apps I find writing large apps with a dialog box popping up after every other statement is counterproductive. With this in mind, I set out to find a better method for displaying debug statements during runtime. Enter C#.

    C# solves three problems I faced when designing the useful and scalable debugging system. These problems exist either in Java, C/C++, or both (my main programming languages).

    1. Not having very much meta-information (e.g. line number, method name, etc.)
    2. Having to add and remove debug statements whenever the debug focus shifts
    3. Having the debug statements compiled into the program affecting performance

    Ok, discussing the solution for these problems in order we’ll start with number one. Basically a few classes from the System.Reflection and System.Diagnostics namespaces solve this problem. Using the System.Diagnostics.StackFrame class the call stack can be explored and stack details such as what is on the stack level above the current one, what line is a function being called from, etc. And with the System.Reflection classes the names of functions, namespaces, variable types, etc., can be ascertained. Applying all this to the problem at hand here’s some code that retrieves the file name, line number, and method name of the function that called it.

    // create the stack frame for the function that called this function

    StackFrame sf = new StackFrame( 1, true );

     

    // save the method name

    string methodName = sf.GetMethod().ToString();

     

    // save the file name

    string fileName = sf.GetFileName();

     

    // save the line number

    int lineNumber = sf.GetFileLineNumber();

    Moving right along to problem number two let’s discuss how to selectively debug different sections of a program during runtime. Number two ties in with number one in that information from number one will help us filter debug statements from being displayed. For this example we’ll filter by namespace. So say that you have fifteen namespaces in your program and right now you only want to display debug statements from one all you would have to do is tell the debug class only allow that one namespace to display debug statements. Simple enough. Here’s some code.

    // create the namespaces hashtable

         namespaces = new Hashtable();

     

         // get the assembly of this class

         Assembly a = Assembly.GetAssembly( new Debug().GetType() );

     

         // now cycle through each type and gather up all the namespaces

         foreach( Type type in a.GetTypes() )

         {

            // check if the namespace is already in our table

            if( ! namespaces.Contains( type.Namespace ) )

               namespaces.Add( type.Namespace, true );

         }

    The above code will create a Hashtable object containing all the namespaces in the same assembly as the Debug class of which this code is a part. Of course, this is only half of the solution so here is the actual filtering code.

         // only proceed if the namespace in question is being debugged

         if( (bool) namespaces[ method.DeclaringType.Namespace ] )

     

    // this is where the debug statement display code would be

    Ok, so far so good. With the problems number one and two knocked out that leaves us with the obstacle of removing those darn debug statements when the final release is to be made without actually having to manually comment out or delete each one. This is where those handy little things called attributes come in to play. Assuming you have knowledge of how attributes work in C# I’ll cut to the chase and introduce the ConditionalAttribute which is part of the aforementioned System.Diagnostics namespace. So here’s some showing how to use the ConditionalAttribute class.

         [Conditional("DEBUG")]

         public void Debug( string msg )

         {

    // this is where the debug statement display code would be

         }

    What this will do is when this program is compiled it will check if ‘DEBUG’ was #defined and if it was then the call to this function will be remain, however if ‘DEBUG’ is not #defined all calls to this function not will be compiled leaving us with no performance hit.

    Now, some of you are probably saying that you could solve some of the problems above in C/C++ and Java. I will note that neither language solves all of them. For example in C/C++ you can #define and #ifdef much like you can use ConditionalAttribute class and C# defines. But getting useful meta-information in C/C++ is limited. And in Java getting meta-information is possible but as far as I know all the code is always compiled (i.e. there’s no Conditional type functionality). Thankfully there is C# which does solve (gracefully I might add) all the problems I mentioned above and quite a few more.

    To demonstrate these techniques I wrote a small windows application along with this article. The Debug class can be plugged into your own projects. So enjoy and happy coding. 


    Please also refer below links

    http://www.eggheadcafe.com/articles/20050511.asp
    http://blogs.msdn.com/b/kaevans/archive/2010/03/26/techniques-in-advanced-net-debugging-with-john-robbins.aspx

    smr replied to aman on 20-Sep-11 05:06 AM
    hi

    Debugging an ASP.NET Web application with Visual Studio .NET is similar to debugging a Windows Form or any other Windows application. The fact that application is running on the Web should be mostly transparent to you.

    In This Section

    http://msdn.microsoft.com/en-us/library/at313d3f(v=vs.71).aspx
    Provides steps for debugging an ASP.NET application during development. These steps include setting debug mode for the configuration file, setting project properties, starting the debugger, setting and clearing breakpoints, stepping, and ending the debugging session.
    http://msdn.microsoft.com/en-us/library/b00hf3c0(v=vs.71).aspx
    Discusses debugging a Web application that is already deployed and running on a server. Information includes considerations and steps for debugging.
    http://msdn.microsoft.com/en-us/library/233w9kd4(v=vs.71).aspx
    Lists prerequisites for debugging a Web application on a remote server.
    http://msdn.microsoft.com/en-us/library/k2h50zzs(v=vs.71).aspx
    Discusses testing scripts and client side scripts in ASP.NET pages. Tasks you can perform when debugging client-side scripts in a Web page include viewing source code, controlling the pace of script execution with breakpoints and stepping, viewing and changing variable and property values, and viewing and controlling script flow with the Call Stack window.
    http://msdn.microsoft.com/en-us/library/aa291236(v=vs.71).aspx
    Describes debugging ASP.NET Web services. Information includes debugging an XML Web service on //localhost, debugging an XML Web service on a remote server, and debugging a deployed XML Web service.
    http://msdn.microsoft.com/en-us/library/kd3se23d(v=vs.71).aspx
    Describes the operating system requirements for debugging ASP.NET Web applications with Visual Studio .NET.
    http://msdn.microsoft.com/en-us/library/e8z01xdh(v=vs.71).aspx
    Discusses setting debug mode for an ASP.NET application. Information includes a description of Web.config files, suggestions for editing the file, sample code, and the behavior of hierarchical configuration files.