The .NET debugger supports most features of the debugger for standard PowerBuilder applications, including expression evaluation and conditional breakpoints. It does not support the Objects in Memory view or variable breakpoints, which are not supported in .NET. Local variables that are declared but not used do not display in the Local Variables view in .NET targets.
Additional debugging restrictions include the following:
Debugger icon display in .NET Web Forms projects When you close a .NET Web Forms application that is being debugged, the Stop Debugging icon remains enabled in the debugger, and the StartDebugging icon is disabled.
Single-stepping between events In the .NET debugger, when you step into a statement or function in an event script, the debugger displays the next line of code. However, if you step into a different event script, the debugger continues execution to the next breakpoint. You should add a breakpoint to each event that you want to debug.
For example, if you have set a breakpoint in the application's Open event, and the script opens a window, the debugger does not step into the window's Open event. You should set a breakpoint in the window's Open event or in a user-defined event that is called from the Open event.
Setting breakpoints in modified code If you modify your code after successfully debugging a .NET application, you must redeploy the application before you debug it again. Although you can still set breakpoints in modified lines of code before you redeploy an application, the debugger debugs only the last deployed version of your application.
Server support restrictions for .NET Web Forms projects The .NET debugger does not support IIS 6 if the maximum number of worker processes is set to greater than one. This is because it cannot determine whether the process to be debugged is newly created or is recycled from a pool of worker processes. (The debugger must attach to the worker process in Web garden mode.) It also does not support the Cassini Web server that ships with .NET Framework 2.0.
Multiple applications using the same PBLs When you run or debug a Web Forms application, its PBLs can remain cached in the ASP.NET process. If you then try to debug a second Web Forms application that shares a PBL with the first application, the ASP.NET process lets the debugger know that the first module is loaded and the debugger binds to breakpoints in that module. In this case, the debugger never binds to breakpoints in the second application. You can avoid this issue by not sharing PBLs among Web Forms projects or by restarting IIS before you begin debugging.
Remote debugging Debugging of Web Forms or Web Service targets is not supported for applications or components deployed to remote IIS servers.
For information about standard PowerBuilder debugger features, see “Debugging an application” in the Users Guide.
