HK1173800B - Design time debugging - Google Patents

Description

Design time debugging

Technical Field

The present invention relates to computers, and more particularly to design-time debugging.

Background

Debugging refers to the process of examining and observing the behavior and state of a computer program during program execution. Conventional debugging tools allow a program to stop executing at a particular line of code or when a particular condition occurs, at which point the developer can check the program state. For example, for variables that are within range, the developer can see the values of these variables at the time of program execution interruption. The developer is also able to run new code in the context of the debugged program and observe the new state of the application and its data structures. This practice is often used to find and correct bugs (bugs) in computer programs so that it executes as intended and in the process of writing new applications or functions, where it is helpful to observe the behavior of existing applications. Debugging is generally a time consuming and tedious task. Debugging tools are often provided to make this work somewhat less cumbersome.

A runtime debug tool is a software tool that allows a developer or tester to monitor the execution of a program. The user can stop or pause the execution of the program, restart the program, set a breakpoint, check a value in memory, change a value in memory, and so forth. Runtime debugging tools provide information about a running instance of a program and are not able to provide information during design time.

Disclosure of Invention

When creating plug-ins (plug-ins), add-ons (add-ons), automation components, or extensions (hereinafter "extensions") for an application with an extensibility model, debugging becomes a useful technique to examine and explore the state of the application when the extensions are run in the context of the application. It is useful to have knowledge of the data structures and object models created based on the different states of the extensions. Today, specifics regarding and extendingInformation for the data structure and object model of the application with which the state is associated is typically provided by runtime debugging the extension when it is executed within the context of a particular instance of the application, and is not available when the extension is not executing. As described herein, information based on data structures and objects of an instance of an application is exposed during conventional interaction with the application without the need to execute and debug the extension. Examples of such applications include, but are not limited to, VisualAndoffice. Examples of such extensions include, but are not limited to, VisualOf medium coloration (colouring) orMacros in Office.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

Drawings

In the drawings:

FIG. 1a is a block diagram of an example of a known runtime debugging system;

FIG. 1a is a block diagram of an example of a design-time debugging system in accordance with aspects of the subject matter disclosed herein;

FIG. 1c is a block diagram illustrating debugging a conventional application during runtime as known in the prior art;

FIG. 1d is a block diagram illustrating an application known in the prior art that debugs during runtime as an extension to an existing body of code;

FIG. 1e is a block diagram that illustrates a representation of source code by a compiler while debugging a design-time using a debug metaphor (debug metaphor) in accordance with aspects of the subject matter disclosed herein;

FIG. 1f is an example of a runtime debug user interface as known in the prior art;

FIG. 1g is an example of a design-time debug user interface in accordance with aspects of the subject matter disclosed herein;

FIG. 2 is a flow diagram of an example of a method for design time debugging in accordance with aspects of the subject matter disclosed herein;

FIG. 3 is a block diagram illustrating an example of a computing environment in which aspects of the subject matter disclosed herein may be implemented; and

FIG. 4 is a block diagram of an example of an integrated development environment in accordance with aspects of the subject matter disclosed herein.

Detailed Description

Overview

Such as Eclipse, and VisualOthers include an array of debugging tools. For example, some IDEs include an interactive, runtime debugger that can be used to debug applications written in any language supported by the IDE. The debugger may be able to attach to a running process inside or outside the IDE to monitor and debug the process. If the source code of the running process is available, the debugger may be able to display the source code while the program is running. If the source code is not available, the debugger may be able to show a reflexionPlaited (discrete).

The debugger also allows a developer or other user to set breakpoints that allow execution to be temporarily stopped at some point in the code, the values of objects created during program execution to be debugged to be checked and changed and execution to resume. The debugger also supports a user interface, such as a watch window (watch windows) in which the values of variables are monitored and displayed as execution of the program continues. Breakpoints can be conditional, meaning that a breakpoint can be triggered when a specified condition is met. The user may be able to execute one line of code at a time, stepping into a function to debug inside the function, or bypassing a function, hiding what happens during execution of the body of the function. In some debuggers, during a debugging session, if a user hovers a mouse pointer over a variable, the current value of the variable may be displayed in a data tool tip (tooltip), where it may also be modified if desired. The debugger may include an expression evaluator feature that may evaluate the expression in context and the application state being debugged.

FIG. 1a is a block diagram of a computer 102 having a processor 142 and a memory 144, such asVisual,Eclipse、Office, or other IDE, etc. known Integrated Development Environment (IDE) 104. IDE104 may include runtime debug module 106, runtime debug module 106 including runtime debug engine 112, runtime debug engine 112 monitoring debug events 108 occurring during execution of process 110 during a debug session and providing one or more debug user interfaces (such as monitor window 114, data tooltip 118, and expression evaluator 116) and accepting user input 126 within the debug user interface. FIG. 1c illustrates debugging a user application during runtime. At IDIn one instance of E128 (example 1), runtime debug engine 132 executing on computer 102 may monitor runtime process 134 being debugged and display source code 130 associated with runtime process 134 being debugged while the debug session is in progress. A runtime debug user interface 136 (e.g., watch window, tooltip, etc.) may be displayed. FIG. 1f (described more fully below) illustrates such a runtime monitoring window.

However, assume that a developer wants to write some code that executes within the context of another program. An example of code that executes in the context of another program is an extension to an application (such as an IDE). For example, assume that the extension code provides a reconfiguration function and that the extension code manipulates the user code by reordering the parameters a and b of function a. Today, to determine whether the extension code executed correctly for function A, developers write the extension code and incorporate the extension into the IDE that includes user items that use some of the code of function A. The developer then obtains a view or representation of the user code by the compiler by launching the compiler within the user project. He attaches the debugger to the parameter reordering code of another instance of the IDE. He inserts a breakpoint in the extension code and, when the breakpoint is encountered, the developer steps through a data structure created by the compiler from the user code to see if the extension code has had the desired effect on the user code.

FIG. 1d illustrates runtime debugging of a program on computer 102 running within the context of a second program as known in the prior art. The program that runs within the context of the second program may be extension code. A first instance (instance 1) of IDE148 (including the executable of the extension code) is instantiated and runtime debug engine 152 may monitor runtime process 158 being debugged and display source code 150 associated with runtime process 158 being debugged. Runtime debug engine 152 is associated with a process (runtime process 158 being debugged) that includes the second instance (instance 2) of IDE154 in which the extension code is running. The runtime debug user interface 156 displays runtime debug information for the debug session and may show a compiler representation of the user code as manipulated by the extension code.

In accordance with aspects of the subject matter described herein, as shown in FIG. 1e, a single instance of the IDE160 is instantiated on the computer 103 as opposed to the above. The design-time editor 163 displays the source code 166 as it is interactively developed by the user. Source code 166 displayed in design time editor 162 may include extension code, i.e., code that acts on or extends the functionality of another application. The extension code may take action for a particular user instance of a type of application. For example, the extension code is extensible for the userA function of the spreadsheet. Alternatively, the extension may extend the functionality of the source code editor for a particular language in an IDE that has loaded a particular user project or the like. During interactive development of the extension code, the design-time editor 162 raises events that represent developer changes to the extension code. Design-time debug engine 164 monitors events raised by design-time editor 162.

In response to events raised by design-time editor 162, design-time debug engine 164 may request information from design-time compiler 170. The requested information may include information about objects created by a compiler associated with code on which the extension acted, information associated with user files including code files, designer artifacts (artifacts), resource files, etc., objects associated with the compiler, objects associated with the IDE in response to user interaction with the IDE. This information may be formatted and displayed in the design-time debug user interface 168, as described more fully below, even if the extension code is not executing. Design-time debugging engine 164 also monitors user interactions in design-time debugging user interface 168, and in response to the interactions, may change the display of source code 166 in design-time editor 162 or change the information displayed in design-time debugging user interface 168. For example, a piece of code in the source code editor may be highlighted in response to user interaction in the design-time debug user interface 168, or the like.

It will be appreciated that in the illustrative, non-limiting example above, the user code being manipulated by the extension code may be a hosted application and the extension code may be a hosted application. Aspects of the subject matter disclosed herein may be similarly applied in other hosting scenarios, such as, but not limited to, any extensible application, including, but not limited toFor example, most browsers are extensible, with plug-ins, Java applets, etc. that support Flash applications. Such a plug-in may display the browser object model when the user interacts with the web page. According to aspects of the subject matter disclosed herein, similar information about a particular state of a hosted application is available during design time of the hosted application and is displayed in a design-time debugging user interface.

Design time debugging

The phrase "software extension" as used herein is a computer program designed to be incorporated into another piece of software to enhance or extend the functionality of the software into which it is incorporated. That is, the software extension is considered to run within the context of or be hosted by another (hosted) application. Other terms used to denote software extensions are add-on (add-on), add-in (add-in), or plug-in (plug-in). Software extensions are generally useless or non-functional in their own right. Examples of software applications that support extensions include VisualAnd Eclipse, browsers such as the Mozilla Firefox Web browser, and Adobe Systems Photoshop,Andwindows Explorer, et al, all provided as extensions. Typically, a potentially unbounded range of applications will feature an extended Application Programming Interface (API). Descriptions of APIs are often exposed so that third party developers can make extensions.

One of the challenges in writing software extensions is to understand the API and data structures of the managed application in any given state of the end-user (managed) program. For example, in a development environment, significant effort is required to understand a language compiler and the data structures created by the language compiler. Today, in order to be able to view the data structure of a managed program, a debugger must be attached to the software extension (managed) code that uses the data structure. In order to be able to attach a debugger to software extension code, a developer must write code within the extension that has a development environment and compiler objects within range. He must set the correct high-level context for these objects (e.g., load into the correct file or item that loaded the extension). After that, it is often necessary to find more specific information to be able to display the relevant part of the data structure. For example, it may not be sufficient to obtain the entire parse tree for a particular open file in the development environment. Conversely, it may be much more useful to display a particular resolution node. More specific context may be provided so that the particular resolution node may be displayed by, for example, using the current position of a cursor in an editor.

After syntactically correcting the code, the developer compiles and deploys the code in the IDE so that the next time the development environment is launched, the extension will be included in the running code. Finally, the development environment is started, the project encapsulating the desired scenario is opened, a debugger is attached to the running application (extension code) and the applicable data structures are investigated using a debugging tool.

For example, assume that a developer is writing a software extension that includes an extension to a compiler and wants to debug the compiler when it runs on a user instance of a command handler. If the developer wants to determine how the compiler looks at the command processing code, he starts the compiler within the user project, attaches a debugger to the compiler process and inserts an interrupt to determine the compiler view of the command handler. That is, the compiler API is investigated when it has a specific state in which the input is a command handler that is executing. Two instances of the development environment are running: in one instance the command handler is running and in one instance the compiler that manipulates the command handler is running.

In contrast, according to aspects of the subject matter disclosed herein, debugging information for a software extension of an active document or project is provided as if a user were debugging code that provided this data. This information is provided by exposing known information about the environment using tools such as compiler watch windows and other conventional runtime debugging user interfaces such as data tooltips and expression evaluators, without creating runtime debugging sessions. Design-time debugging information is automatically provided without user intervention when a user changes the application state.

FIG. 1b illustrates an example of a system 101 that performs design-time debugging on a computer 103 in accordance with aspects of the subject matter disclosed herein. All or portions of system 101 may reside on one or more computers such as the computers described below with reference to fig. 3. All or part of system 101 may reside on one or more software development computers, such as the computers described below with reference to FIG. 4. The system 101, or portions thereof, may comprise a portion of an integrated development environment (e.g., the IDE105) such as those described and illustrated below with reference to fig. 4. Alternatively, system 101 or portions thereof may be provided as a stand-alone system or as a plug-in or add-in.

The system 101 may include one or more of the following: a processor (such as processor 142), memory 144, and design-time debug module 107. Other components known in the art may also be included but are not shown here. It will be appreciated that design-time debug module 107 may be loaded into memory 144 to cause one or more processors, such as processor 142, to perform the actions attributed to design-time debug module 107. In accordance with aspects of the subject matter disclosed herein, design-time debug module 107 may receive one or more of the following: user input 127 and one or more data sources (not shown) and displayed substantially simultaneously in the design-time debug user interface: the source code of the extension (first program) under interactive development and runtime debug information based on data structures and/or objects associated with the instance of the extensible IDE are not executed. Information displayed in the design-time debugging user interface may be displayed automatically (e.g., without human intervention requesting that the information be displayed). Moreover, information displayed in the design-time debug user interface may be automatically changed in response to user interaction manipulating the application. For example, information displayed in the design-time debugging user interface may be automatically changed in response to user interaction manipulating the source code of the IDE or by user interaction manipulating information presented in the design-time debugging user interface. The information presented in the design-time debug user interface may include runtime debug information based on execution of the application (second program).

The design-time debug module may include one or more of the following: an application associated with a user interface and with an extensibility API that allows a user to view and manipulate the data structures of the application. For example, the design-time debug module may include a module such asAnd the like, and the like are applied,user interface with programmatic tasks enabling a user to set up electronic forms and use macros and to allow a user to view and manipulate the sameExtensibility API of the generated data structure.

Design-time debug module 107 may include one or more of the following: an editor 109, a compiler 111, and a design-time debug engine 113. The editor 109 may comprise a source code editor. The editor 109 may generate a design-time editing event based on user input manipulating the source code of the first program, a change to a cursor position or focus in the source code editor, editing or manipulation of a source code file, or by receiving an event caused by a user clicking on an associated menu item. The editor 109 may send a design time editor event to the design time debug engine 113.

Design-time debug engine 113 may request updated views of data structures, objects, etc. from compiler 111 based on the received editor events. Compiler 111 may represent a background compiler, a dynamic parser, or a parallel compiler. While code is being written, such a compiler may compile the code in the background to provide feedback on syntax and compilation errors, which may be marked with indicators such as red wave underlining. Warnings may also be marked, such as with a green underline, and the like. Compiler 111 may generate or refresh a language model and send a refreshed view of the current language model, compiler-generated objects, compiler-generated data structures, IDE objects, IDE data structures, etc. to design-time debug engine 113 in response to a request received from design-time debug engine 113.

The design-time debugging engine 113 may generate runtime debugging information based on information received from the compiler 111 or application and display the runtime debugging information in a design-time debugging user interface, such as a debugger window, available at design time when the end user is interactively writing code. The information that populates the design-time debugging user interface may be responsive to user events such as changes to cursor positions in a source code editor, edits to source files, user interactions by receiving events such as events caused by a user clicking on related menu items, or by user interactions with the design-time debugging user interface.

When design-time debug engine 113 detects or receives such an event, design-time debug engine 113 may require compiler 111 to flush a representation of a data structure or object associated with the instance of the second program or a representation of a data structure or object associated with the compiler or IDE by the compiler. Information returned by the compiler to the design-time debug engine 113 can be presented to the user through a design-time debug user interface that is similar to a traditional runtime debug user interface displayed during a traditional runtime debug session. The design-time debug user interface includes, but is not limited to, a watch window 115, an expression evaluator 117, and a data tooltip 119. The information displayed in the design-time debug user interface presents information based on a compiler view of the state of the managed (second) program. The information may include information about files, compiler objects, and references. It will be appreciated that this runtime debug information is displayed without executing the first program during the development of the first program during design time.

Design-time debug engine 113 may also monitor user interaction with the design-time debug user interface. In response to detecting user interaction within the editor 109 or within the design-time debugging user interface, the content of the information displayed within the design-time debugging user hypothesis may be automatically refreshed or modified. In response to detecting a user interaction within the design-time debugging user interface, an appearance of information displayed in the design-time editor may be automatically modified, e.g., a piece of source code may be highlighted, etc.

FIG. 1f is a representation of an example of a display 172 that may be displayed during a runtime debugging session, as is currently known in the art. A part of the display 172 displays the source code of the program consolete application17 (console application 17) 174. The program Console application 17174 creates a variable x of type Element, assigns "fff" to x (line 177), and writes the value of x on the console. Breakpoint 176 has been placed in console. On this line. During execution of Console application17, when a breakpoint is reached, execution of Console application17 stops and a runtime debug monitor window Watch1 (monitor 1)178 is displayed. Watch 1178 displays the value 180 ("fff") of x and the type 182 of x (System. XElement …), different Attributes of x (First Attribute), Has Attributes (with Attributes), Has Elements (with Elements), Is Empty, LastAttribute (last Attribute), and so on. For each Attribute, the information shown may be expanded so that all members of this Attribute are displayed, for example, by clicking on the plus sign before First Attribute. The information shown in this runtime debug session reflects the information known about the actual object pointed to by x, which was created during execution of the program Console application 17174.

In contrast, FIG. 1g is an example of a display 184 of a design-time debugging user interface 188 that may be displayed during interactive design-time development of software extension code Module1 (Module 1)186 in an editor. When the developer types in the code of the Module 1186 in the design-time editor, a design-time debugging user interface, such as the design-time debugging user interface 188, is automatically displayed. No debug session is initiated. Module1 (Module 1) is not executing. As the developer navigates within the code (e.g., using a cursor), the design-time debug user interface displays information about the compiler object associated with the point at which the cursor is located. The information displayed in the design-time debug user interface 188 may include information on the types inherent to the compiler 111 and the objects created by the compiler 111 to represent the types of members associated with the description of the source code, the data structures and objects created by the compiler 111, and the data structures and objects associated with the IDE in which the compiler is executing.

For example, the design time debug user interface 188 displays a call declaration node CallStatementNode190, which is a representation of the compiler's control console writeline method call (Console. WriteLine ("fff")) line 187. CallStatementNode190 represents an object that describes line 187 in source code 186. By viewing the design-time debugging user interface 188, the value (system. collections. object) 192 of the CallStatementNode190 can be determined, as can the type of CallStatementNode 190: (.VisualBasic.Syntax.CallStatement) 194. The design time debug user interface 188 displays information about the children of the CallStatementNode 190. One of the children of the CallStatementNode190 is the method to be called. The method to be called is represented by an attribute QualifiedNode196, which points to the object representing the method. The value of the object pointed to by QualifiedNode196 is console. The type of QualifiedNode196 is one of the types within compiler 111:visual basic. syntax. qualifieldnode. The design-time debug user interface 188 thus displays a tree structure that represents a syntax tree of code (e.g., source code 186) displayed in the source code editor. The root node of the tree is a call declaration node that represents the entire line of code. The tree itself includes a subtree representing the called method, arguments to the method, and so on. Each of the items displayed in the design-time debugging user interface 188 may itself be examined by selecting the item to expand.

FIG. 2 illustrates an example of a method 200 of performing design-time debugging in accordance with aspects of the subject matter disclosed herein. Source code of a first program executing within the context of a second program under interactive development during design time is displayed substantially simultaneously with debugging information based on data structures and objects associated with an instance of the second program. A design-time debug engine, such as the design-time debug engine described above with reference to fig. 1b, 1e and 1g, monitors editor events generated as a result of user input received by a design-time editor (such as editor 109). The design-time debug engine also monitors events generated as a result of user input in the design-time debug user interface described above. User input within the source code editor may include source code in the development and editing of software extensions.

When the design-time debug engine detects an edit event 280, the design-time debug engine requests an application or compiler (such as compiler 111 described above) to refresh its view 282 of the data structures and objects associated with the second program. In response to receiving the updated information 284 from the compiler, the design-time debug engine displays design-time debug information 286, as described above with reference to FIG. 1 g. When the design-time debug engine detects user interaction 280 with the design-time debug user interface, the design-time debug engine requests that a compiler (such as compiler 111 described above) can request different views of the data structures and objects associated with the second program. In response to receiving the updated information 284 from the compiler, the design-time debug engine displays design-time debug information 286, as described above with reference to FIG. 1 g. In a manner similar to the behavior of the runtime debug user interface, the design-time debug engine may also monitor and respond to user interactions with the design-time debug user interface, modifying the display of source code in the editor. For example, in response to receiving user input selecting a node in a design-time debugging user interface, a segment of source code displayed in the editor corresponding to the node may be highlighted in the editor. When a user types an expression in a design-time monitoring window, the results of this expression may be reflected in the application itself, e.g., in the source editor.

Examples of suitable computing environments

In order to provide context for various aspects of the subject matter disclosed herein, FIG. 3 and the following discussion are intended to provide a brief, general description of a suitable computing environment 510 in which embodiments may be implemented. While the subject matter disclosed herein is described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other computing devices, those skilled in the art will recognize that portions of the subject matter disclosed herein also can be implemented in combination with other program modules and/or combinations of hardware and software. Generally, program modules include routines, programs, objects, physical artifacts, data structures, etc. that perform particular tasks or implement particular data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments. The computing environment 510 is only one example of a suitable operating environment and is not intended to suggest any limitation as to the scope of use or functionality of the subject matter disclosed herein.

With reference to FIG. 3, a computing device for software development in the form of a computer 512 is depicted. The computer 512 may include a processing unit 514, a system memory 516, and a system bus 518. The processing unit 514 can be any of various available processors. Dual microprocessors and other multiprocessor architectures also can be employed as the processing unit 514. The system memory 516 may include volatile memory 520 and non-volatile memory 522. Non-volatile memory 522 may include Read Only Memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), or flash memory. Volatile memory 520 can include Random Access Memory (RAM), which can act as external cache memory. The system bus 518 couples system physical artifacts including the system memory 516 to the processing unit 514. The system bus 518 may be any of several types of bus structures including a memory bus, memory controller, peripheral bus, external bus, or local bus and may use any of a variety of available bus architectures.

Computer 512 typically includes a variety of computer readable media such as volatile and nonvolatile media, removable and non-removable media. Computer storage media may be implemented by any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer-readable storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer 512.

It will be appreciated that FIG. 3 describes software that can act as an intermediary between users and computer resources. The software may include an operating system 528, which can be stored on disk storage 524, and which can control and allocate resources of the computer system 512. Disk storage 524 may be a hard disk drive connected to the system bus 518 through a non-removable memory interface such as interface 526. System applications 530 take advantage of the management of resources by operating system 528 through program modules 532 and program data 534 stored either in system memory 516 or on disk storage 524. It is to be appreciated that a computer can be implemented with various operating systems or combinations of operating systems.

A user may enter commands or information into the computer 512 through input device(s) 536. Input devices 536 include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, and the like. These and other input devices connect to the processing unit 514 through the system bus 518 via interface port(s) 538. Interface port(s) 538 may represent a serial port, a parallel port, a Universal Serial Bus (USB), or the like. The output device 540 may use the same type of port as the input device. Output adapter 542 is provided to illustrate that there are some output devices 540 like monitors, speakers, and printers that require special adapters. Output adapters 542 include, but are not limited to, video and sound cards that provide a connection between the output device 540 and the system bus 518. Other devices and/or devices or systems, such as remote computer 544, may provide both input and output capabilities.

The computer 512 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 544. The remote computer 544 can be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 512, although only a memory storage device 546 has been illustrated in fig. 4. Remote computer(s) 544 may be logically connected via a communication connection 550. Network interface 548 encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN), but may also include other networks. Communication connection(s) 550 refers to the hardware/software employed to connect the network interface 548 to the bus 518. Connection 550 may be internal or external to computer 512 and include internal and external technologies such as modems (telephone, cable, DSL and wireless) and ISDN adapters, ethernet cards and so on.

It will be appreciated that the network connections shown are examples only, and other means of establishing a communications link between the computers may be used. One of ordinary skill in the art can appreciate that a computer 512 or other client device can be deployed as part of a computer network. In this regard, the subject matter disclosed herein relates to any computer system having any number of memory or storage units and any number of applications and processes occurring across any number of storage units or volumes. Aspects of the subject matter disclosed herein may apply to an environment with server computers and client computers deployed in a network environment, having remote or local storage. Aspects of the subject matter disclosed herein may also apply to a standalone computing device, having programming language functionality, interpretation and execution capabilities.

FIG. 4 illustrates an Integrated Development Environment (IDE)600 and a common language runtime environment 602. The IDE600 may allow a user (e.g., developer, programmer, designer, coder, etc.) to design, code, compile, test, run, edit, debug, or build programs, assemblies of programs, websites, web applications, and web services in a computer system. The software program may include source code (component 610) created in one or more source code languages (e.g., Visual basic, Visual J #, C + +, C #, J #, Java Script, APL, COBOL, Pascal, Eiffel, Haskell, ML, Oberon, Perl, Python, Scheme, Smalltalk, etc.). The IDE600 may provide a native code development environment, or may provide managed code development running on a virtual machine, or may provide a combination thereof. The IDE600 may provide a managed code development environment using the NET framework. An intermediate language component 650 may be created from the source code component 610 and the native code component 611 using a language specific source compiler 620, and the native code component 611 (e.g., machine executable instructions) may be created from the intermediate language component 650 using an intermediate language compiler 660 (e.g., a just-in-time (JIT) compiler) when executing the application. That is, when an IL application is executed, it is compiled while being executed into the appropriate machine language for the platform on which it is being executed, thereby enabling code to be portable across several platforms. Alternatively, in other embodiments, the program may be compiled into a native code machine language (not shown) suitable for its target platform.

A user may create and/or edit source code components via the user interface 640 and source code editor 651 in the IDE600 according to known software programming techniques and the specific logical and syntactic rules associated with a particular source language. Thereafter, the source code component 610 can be compiled via a source compiler 620, whereby an intermediate language representation of the program, such as assembly 630, can be created. The assembly 630 can include an intermediate language component 650 and metadata 642. The application design may be able to be verified before deployment.

The various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the methods and apparatus disclosed herein, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing aspects of the subject matter disclosed herein. In the case of program code execution on programmable computers, the computing device will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs that may utilize the creation and/or implementation of domain-specific programming models aspects, e.g., through the use of a data processing API or the like, may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

While the subject matter disclosed herein has been described in connection with the appended drawings, it is to be understood that modifications may be made to perform the same function in a different manner.

Claims (15)

1. A system for design-time debugging, comprising:

a processor of a software development computer;

a memory coupled to the processor;

a design-time debug module loaded into the memory, the design-time debug module automatically displaying, substantially simultaneously during design-time of the first program:

designing source code of the first program in a source code editor, wherein the first program executes within the context of a second program; and

runtime debugging information in a design-time debugging user interface, the runtime debugging information based on a data structure or object associated with an instance of the second program without executing the first program.

2. The system of claim 1, further comprising the design-time source code editor, the design-time source code editor to generate a design-time editor event based on user input manipulating the source code of the first program and to send the design-time editor event to the design-time debugging module.

3. The system of claim 1, wherein in response to detecting user input manipulating the runtime debugging information displayed in the design-time debugging user interface, the design-time debugging module modifies an appearance of the source code of the first program in the design-time source code editor or modifies content of debugging information displayed in the design-time debugging user interface.

4. The system of claim 1, wherein the design-time debugging user interface comprises a compiler watch window, a data tooltip, or an expression evaluator.

5. The system of claim 1, wherein the content of the design-time debugging user interface changes in response to a cursor position in the design-time source code editor.

6. A method for design-time debugging, comprising:

displaying, substantially simultaneously during design time for an extension of the extensible application:

source code for the extension in a design-time editor executing on a software development computer, wherein the extension executes within the context of the extensible application, and

debug information in the design-time debug user interface based on data structures and objects associated with the instance of the second program (286).

7. The method of claim 6, further comprising:

receiving a design-time editor event during the extended design time period, wherein the design-time editor event comprises an event generated in response to a user input manipulating the extended source code.

8. The method of claim 7, further comprising:

in response to receiving the design-time editor event, sending a request for information about a data structure or object associated with the instance of the extensible application.

9. The method of claim 6, further comprising:

modifying an appearance of the source code of the extension in response to detecting user input manipulating the debugging information based on the data structures and objects associated with the instance of the extensible application.

10. The method of claim 6, further comprising:

modifying debugging information based on the data structures and objects associated with the instance of the extensible application in response to user input manipulating the source code of the extension or in response to user input manipulating the debugging information in the design-time debugging user interface.

11. A method for design-time debugging, comprising:

displaying runtime debugging information in a design-time debugging user interface based on a compiler and an integrated design environment data structure associated with a first program while displaying source code of a second program during design-time of the second program, the second program comprising extension software, wherein the first program executes within a context of the second program.

12. The method of claim 11, further comprising:

displaying runtime debugging information in the design-time debugging user interface based on the compiler object and the integrated design environment object.

13. The method of claim 11, further comprising:

changing an appearance or content of a display of the source code of the second program in response to user input in the design-time debugging user interface.

14. The method of claim 11, further comprising:

changing content of a display of the design-time debugging user interface in response to user input in the design-time debugging user interface, or changing content of a display of the design-time debugging user interface in response to user input in the source code of the second program.

15. The method of claim 11, further comprising:

displaying runtime debugging information without initiating a runtime debugging session, the runtime debugging information being displayed in the design-time debugging user interface, the design-time debugging user interface including a monitoring window, a data tool prompt, or an expression evaluator.