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 appear
in the Local Variables view in .NET targets.
Additional debugging restrictions include the following:
- Debugger icons appear 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 shows the next line of code.
However, if you step into a different event script, the debugger
continues execution to the next breakpoint. 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.
- 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 Users
Guide > Debugging an application.