KNOWN ISSUES OF .NET SCRIPT EXECUTING AND DEBUGGING
In our products and solutions, we rely heavily on Microsoft compiler services to provide C# and Visual Basic scripting capabilities to extend .NET applications with user-defined logic. Certain limitations come with this technology; we list below the most common ones experienced by our customers:
Memory consumption
.NET scripts accessing application-defined objects must be compiled by Microsoft .NET Compiler into .NET assemblies (DLLs) and loaded into an application domain. These assemblies cannot be unloaded afterward, potentially creating problems due to the application memory footprint growing if scripts are constantly updated/recompiled.
To deal with these DLLs accumulated in application memory, applications can compile scripts into a separate executable (or into .NET DLLs loaded in a different application domain). Then these DLLs can be safely unloaded when the script finishes its work. In both cases, scripts can access application-defined objects via interprocess-communication, i.e., .NET remoting.
Please refer to the following example of how the application can execute scripts in the separate application domain:
Script Debugging Limitations
AlterNET Script Debugger is based on the NET Framework Command-Line Debugger (mdbg), built on top of ICorDebug interfaces. These interfaces are included in .NET Framework and used internally by the Visual Studio debugger.
During a debugging session, .NET Script Debugger is attached to a managed process and waits for some debug event (i.e., hitting breakpoints). It then stops all threads in that process allowing inspecting variables, a call stack evaluation, continuing the process, or a step-by-step execution.
The Script Debugger provides process-wide debugging, meaning that a script being debugged has to run in a separate process; otherwise, the debugger will freeze itself when stopping the debugging process.
It leaves two ways of incorporating a .NET Script debugger into your applications. First is when Script Debugger is a separate executable that can be attached to the primary application process and debug .NET scripts executed by the application. The second is when the primary application contains script debugging logic and compiles scripts into a separate executable. Latter means these scripts can only access application-defined objects through interprocess-communication techniques (i.e., .NET remoting).
Please note that debugging an application with Visual Studio and debugging scripts in this application using Script Debugger simultaneously is impossible, as Windows supports only one debug process to be attached to the application process.
Please refer to DebugMyScript and DebugRemoteScript quick-start projects installed as part of AlterNET Studio for details of implementing both approaches.
Running debuggers as separate tool is not uncommon in the industry. For example, VBA Macro debugging for Microsoft Office applications is implemented as a separate tool. The power and speed of .NET run-time execution can compensate for the inconveniences related to the limitations described above.
We recognize that some users might need scripting execution and debugging to be part of the same application; in the subsequent articles, we're going to blog about alternative scripting technologies allowing to implementation of this functionality.
