Debugging allows you to step through code and identify and correct programming errors.
Any incorrect statements are underlined in blue in the Code Editor
Syntax errors can often be solved by using the online help to learn more about the error message.
In break mode you can examine the value of properties and variables but you cannot change the program code in the Code Editor. (View > Debug Toolbar)
(F10) - Step Over. Does not step into the current method and advances Visual Studio to the next statement.
(F11) - Step Into. Advanced to the next statement unless it is a method call in which it drops inside for line-by-line.
(F5) - Runs the project with debugging. Execution continues until either a breakpoint is reached or the program ends.
(Ctrl + F5) - Runs the project without debugging.
(Shift + F5) - Stop. Debugging stops and returns Visual Studio to design mode.
(Shift + F11) - Step Out. Completes and steps out of the current method.
Enable the Exception Assistant - (Debugging, General) Displays an informative 'Exception Assistant' dialog box when a run-time exception is thrown.
Break when exceptions cross AppDomain or Managed native boundaries - (Debugging, General) In managed or mixed-mode debugging the common language runtime can catch exceptions that cross application domain boundaries or managed/native boundaries when certain conditions are meet.
Step over properties and operators (Managed only) - (Debugging, General) Prevents the debugger from stepping into properties and operators in managed code.
Class Name drop-down on the left
Method Name drop-down on the right
Visual Studio.NET creates two types of executable files a debug build and a release build. Debug builds contain additional debugging information and are used when testing and debugging yoru program.
To run a program, select (Debug > Start) or press F5
To change between debug and release, (Build > Configuration Manager)
It is always a good idea to recompile your code using (Build > Build Solution) when you reach an important milestone in you rdevelopment or if you are switching from debug to release build. This creates a bin folder in which yoru project is located.
(Debug > Exceptions)
Select Common Language Runtime Exception
Select both "thrown" and "user unhandled" check boxes
When a common language runtime exception is thrown, it will break into the debugger even if you write code to handle the exception using a Try-Catch statement.
By default visual studio does not display errors that are thrown by Microsoft Office 2003 applications.
This is why it is important to check the debugging options and change them where necessary.
(Tools > Options) Debugging Node
select "Break when exceptions cross appdomain or managed ??
(Debug > Exceptions)
Select "thrown and user-unhandled checkboxes next to Common Language Runtime Exception node and press OK
Be able to get the error to break at the exception line (tools > Options ???)
Editor - option to display line numbers
Excel Locale1033 Attribute
Relevant if you are debugging Excel solutions
By default this is set to true which means that data passed to the Excel object model is formatted as English (US) regardless of the locale set on the computer.
This is the same behaviour as VBA
Assembly: ExcelLocale10033(False) in the AssemblyInfo.vb file
Make sure you reset it back to True before deploying your solution.
System.Diagnostics.Process.Start("mailto:" + "email address");
© 2017 Better Solutions Limited. All Rights Reserved. © 2017 Better Solutions Limited