Debugging with Dynamic Languages for ASP.NET, Part 2

Adding Controls and Code for Debugging

You can now add some controls to the page and then add code. The code will be simple, but enough to enable you to add breakpoints later.

To add controls and code for debugging

1. Switch to Design view, and then from the Standard tab of the toolbox, drag the following controls onto the page and set their properties as indicated:

   Control
   Properties

   Label
   ID: CaptionLabel
   Text: (empty)

   TextBox
   ID: NumberTextBox
   Text: (empty)

   Button
   ID: SquareButton
   Text: Square

   Label
   ID: ResultLabel
   Text: (empty)

   Note  For this walkthrough, the layout of the page is not important.

2. Right-click the page and click View Code.

   In this release, event handlers must be coded and bound manually. You cannot create them by double-clicking a control in Design view or by selecting an event in the Properties window.

3. Add an event handler for the button's Click event, with logic to call a function named Square to square the number entered by the user. The handler might look like the following example.

   Note   The code example deliberately does not include error checking.

   IronPython

   		
   def SquareButton_Click(sender, e):
   number = float(NumberTextBox.Text)
   result = Square(number)
   ResultLabel.Text = '%s squared is %8.2f' % \
   (NumberTextBox.Text, result)

   IronPython

   		
   def Square(number):
   return number + number

4. Add code to set the text of the CaptionLabel control to Enter a number: if this is the first time the page is running, and thereafter to Enter another number:. The handler will look like the following.

   IronPython

   		
   def Page_Load(sender, e):
   postback = sender.IsPostBack
   if IsPostBack:
   CaptionLabel.Text = "Enter another number: "
   else:
   CaptionLabel.Text = "Enter a number: "

   You can use the IsPostBack property by itself, as shown in the if statement, or qualified by sender, as shown in the assignment statement. When it is used by itself, it is recognized as a property of the script page just as it is in C# and Visual Basic. In the assignment statement, sender.IsPostBack is used because later in the walkthrough it illustrates a limitation of debugging in the current release.

   Note  In this case, sender and the implicit page reference happen to be the same, because Page_Load handles a page event.

5. Save the page.
6. Press CTRL+F5 to run the page without debugging.
7. Enter a number (other than 2) and press the Square button.

   Notice that the result is incorrect, because there is an intentional bug in the program.

8. Close the browser.

Debugging the Page

In this part of the walkthrough, you will use the debugger to examine the page code line by line as it is running, add breakpoints to the code, and run the page in debug mode. You will start by setting breakpoints.

To set breakpoints

1. In Source view, set a breakpoint on the following line:

   IronPython

   		
   postback = sender.IsPostBack

   Note  When your code is in a separate file, you can toggle breakpoints by pressing F9, by right-clicking a line and choosing Breakpoint, or by clicking in the margin to left of the line. In this release, the only mechanism that works for code embedded in a Web page is clicking in the margin.

2. Set another breakpoint on the following line of the SquareButton_Click handler:

   IronPython

   		
   result = Square(number)

You are now ready to run the debugger.

To run the debugger

1. In the Debug menu, click Start Debugging (or press F5) to run the page in debug mode.

   Note  The first time you debug, you will be prompted to modify the Web.config file to enable debugging. Debugging is disabled by default, for better performance.

   Because the breakpoint is in the Page_Load event handler, the page has not finished processing yet. The browser is open, but the page is not yet displayed.

2. Click the postback variable and press SHIFT+F9 to display its value in a Quick Watch window. The value is null.

3. Note  In this release, the Locals window, the Watch and QuickWatch windows, and the Immediate window are limited to local variables in IronPython.

4. Press F10 to execute the assignment statement, and check the value of postback (IronPython only) to see that it is now false.
5. In the Debug menu, click Windows and then click Locals.

   This opens the Locals window, which displays the values of variables and objects that are in scope at the current line being executed (IronPython only). The value of postback is false.

   Notice that sender, IsPostBack, CaptionLabel, and SquareButton do not appear in the Locals window.

6. In the Immediate window, use the question mark operator to examine the value of postback (IronPython only).

   The Immediate window display will look like the following:

   >? postback
   >false

7. In the Debug menu, click Windows, click Watch, and then click Watch 1 (IronPython only).

   Note:  If you are using Visual Studio Express Edition, the debugger offers only a single Watch window.

8. Right-click postback, then click Add Watch to add the postback variable to the watch.

   Note  In the current release, you cannot right-click to add a watch if the code is in the page instead of in a separate file. Instead, you can enter the name of the variable in the first cell of the Name column in the Watch window.

9. Press F10 several times to step through the if statement.

   When the last line of the if statement has executed, the execution pointer pauses on the next function. The body of the Page_Load method is still in scope, as you can see from examining the Locals window.

10. Press F5 to continue execution and display the page.
11. Enter the value 7 into the text box and click the Square button.

    The debugger is displayed again, with the breakpoint in the Page_Load event handler. Press F10 to execute the line. The Watch window shows that the value of postback is true.

12. Press F5 to continue.

    The debugger processes the Page_Load event handler and enters the SquareButton_Click handler, where it stops on the second breakpoint you set.

13. Press F11 to step into the Square function.
14. Continue stepping through the function until you return from it.

    Notice that the value of result still is not set (IronPython only).

15. Press F11 one more time, and note the incorrect value.

    In the current release, you have to stop the debugger in order to correct the code.

16. Press F5 to continue running the program.

Posted in: Website-asp.net| Tags: asp.net Dynamic Data IronPython Debugging Debug

---

Debugging with Dynamic Languages for ASP.NET, part 1

Introduction

Visual Studio provides you with tools to help find errors in your ASP.NET Web pages. In this walkthrough, you will use the debugger with dynamic languages. The debugger enables you to step through the page's code line by line and examine the values of variables.

In the walkthrough, you will create a Web page that uses dynamic language code to create a simple calculator that squares a number. After creating the page (which will include a deliberate error), you will use the debugger to examine the page as it is running.

Tasks illustrated in this walkthrough include:

• Setting breakpoints and stepping through code.
• Invoking the debugger from a Web page in a file system Web site.

Prerequisites

In order to complete this walkthrough, you will need:

• Microsoft Visual Studio 2008 or Visual Web Developer 2008 Express Edition.
• A copy of the website included in the ASP.NET Dynamic Language Support download. There is currently no project template, so it is necessary to copy the website in order to start with a blank ASP.NET Dynamic Language website.

This walkthrough assumes that you have a general understanding of working in Visual Web Developer or Visual Studio. For an introduction, see Walkthrough: Creating a Basic Page in Visual Web Developer.

Creating the Web Site

In the first part of the walkthrough, you will create a page that you can debug.

If you have already created a Web site in Visual Studio (for example, by working with Walkthrough: Using Dynamic Languages with ASP.NET) you can use that Web site and skip to "Creating a Page to Debug" later in this walkthrough. Otherwise, create a new Web site and page by following these steps.

To create a Web site with a default ASP.NET Web page

1. Copy the files from the ASP.NET Dynamic Language Support project into an empty directory.
2. In Visual Studio (or Visual Web Developer), in the File menu, click Open Web Site. The Open Web Site dialog box is displayed.
3. Select the directory in which you copied the files in step 1. Make sure that FileSystem is selected in the left panel of the dialog.

   Note: You can use statically compiled languages in the same Web application by creating pages and components in different programming languages.

4. Click Open. Visual Studio opens the folder as a website and displays the files in the Solution Explorer.

Creating a Page to Debug

For this walkthrough, it is important that you create a new page as specified in the following procedure.

To add a page to the Web site

1. Close the Default.aspx page.
2. In Solution Explorer, right-click the name of your Web site and then click Add New Item.
3. Under Visual Studio installed templates, select Web Form.
4. In the Name box, enter DebugPage.aspx. The language defaults to your selected dynamic language.
5. Make sure that the Place code in separate file check box is checked.

   In this walkthrough, you are creating a page with the code in a separate file. The code for ASP.NET pages can be located either in the page or in a separate class file.

6. Note  In this release, there are small differences in the way breakpoints and watches can be set, depending on whether the code is in the page or in a separate file. The walkthrough calls out these differences.

7. Click Add.

Posted in: .NET Framework Website-asp.net| Tags: asp.net Dynamic Data Debugging Debug

---

Code Protection Best Practices, Part 2

Debugging Protected Assemblies

The Secure Virtual Machine (SVM) protection process does not provide reversing tools, however, you can use the following guidelines to simplify the analysis of unexpected errors that occur within protected methods.

• Do not use method cloaking. Method cloaking can obscure the call stack at the error point. This is good to impede hacking, but makes life very difficult when analyzing the source of an error. This feature is turned off by default.
• When throwing exceptions or logging errors (during development of the unprotected code) insert a unique error identifier for each location in the code (e.g. a GUID). This will leave the code obscure, but will allow the developer to pinpoint the line that generated the error based solely on this identifier.

Unsupported Method Constructs

SLP Code Protector does not support the transformation methods with the following constructs.

• Methods within generic classes.
• Methods containing explicit instantiation of generic types.
• Methods with generic parameters.
• Non-static methods of a structure.
• Methods with out or ref parameters.
• Methods that invoke other methods with out or ref parameters.
• Methods that modify any method parameter, even if the parameter is defined as a by value parameter.
• Methods with a variable number of parameters (for example, the params keyword in C#).
• Methods with too many local variables or parameters (> 254).
• Methods that contain calls to Reflection.Assembly.GetExecutingAssembly method, Reflection.MethodInfo.GetCurrentMethod method, or Reflection.Assembly.GetCallingAssembly method.
• For the Microsoft Common Language Runtime (CLR) 1.1 only: methods that create objects by using constructors with a variable number of parameters. This restriction does not exist when a non-constructor method is invoked.
• Implicit and explicit cast operators cannot be transformed to the Secure Virtual Machine (SVM).
• Unsafe code – For example, in C#, methods that contain the keyword unsafe cannot usually be transformed.

If you attempt to perform an SVM transformation on a method that violates one of the unsupported constructs in this section, SLP Code Protector will issue a warning.

Posted in: .NET Framework| Tags: Code Protection Best Practice .NET Code Debugging Parameter identifier part protection method methods error ref

---