barcodelib.barcode.asp.net.dll download The Debugging Process in VB.NET

Creating Denso QR Bar Code in VB.NET The Debugging Process

Debugging may or may not be your favorite activity when developing software, but the same general frame of mind you use for developing code can be applied to debugging. Debugging is just another form of problem solving. Having a plan of attack to discover the source of a bug is invaluable. Here are the steps you should follow when you know of a bug and need to go about fixing it: 1. Get to know the system: If you re unfamiliar with the system you re fixing, you should get enough familiarity to do as good a job as possible at fixing the bug without introducing new bugs. Knowing how the system works, what components it uses, and what technologies are involved (e.g., IIS, ASP.NET, Windows Workflow Foundation) can also possibly give you more clues to narrowing down the bug. Reproduce the bug: You must know what you re fixing in order to fix it. Sometimes you re lucky enough to have a consistent reproduction; sometimes you aren t. The goal here is to have the smallest piece of code or the shortest sequence of actions that reveals the bug.

Make a guess: Sometimes by making a guess you can identify the bug right away. This isn t always possible, but when it works, you appear to have special powers. Raymond Chen calls this psychic debugging. It s really just a matter of having enough experience to know the source of a bug based on symptoms. If you can t solve the bug immediately, sometimes a guess will at least get you closer to the source of it in the code. Gather evidence: Solving a bug isn t the most difficult activity as long as you have a solid plan. Part of this plan is to analyze the evidence at your disposal usually bug reports, error/audit logs, analysis tools such as file/registry activity monitors, and so on. Conduct heavy debugging: If you haven t discovered the source of the bug yet, then now is likely the time to step through code in a debugger. This can be a slow process, depending on how close you can get to the bug, but it will typically give you a clear view of the system at a line-by-line level. Identify the solution: By now you ve found the source of the bug. Sometimes a bug fix is straightforward; other times you must be careful not to affect other parts of the system. A strong set of unit tests is invaluable at this point. If you fix the bug but introduce a new bug, or reintroduce an old bug (a regression), the unit tests can identify this and you can revisit your solution. Apply the fix: You ve identified the solution, implemented it, and verified it hasn t broken any existing tests. After applying the fix, you may have to update unit tests or add new unit tests. Accordingly, you will probably perform integration testing and regression testing as part of your functional and usability testing to confirm that there is no adverse effect on the applied fix.

Let s take a closer look at some tools and techniques that can save you time when you are debugging Silverlight applications.

Much like .NET assemblies, Silverlight assemblies can be compiled in a debug mode configuration or a release mode configuration. The main differences between debug and release mode are which conditional symbols are defined and whether symbols are generated along with the assembly. For debug mode, the preprocessor symbol DEBUG and TRACE are automatically defined, and for release mode, TRACE is defined. Sometimes implementing code only for purposes of debugging can be extremely useful. For example, an application might write a significant amount of information to a log file for debugging only. This code can t run in production applications due to performance reasons, and optimally we want to get rid of this code completely. This can be achieved with conditional compilation. The best approach to conditional compilation is to use #if...#endif to isolate blocks of code that must only appear in certain configurations. Generally, these are used to only put debug code in debug builds for example, writing to a debug trace log. private void login() { #if DEBUG traceLog.WriteLine("entered login method");