Join  |  Sign in
Known issues of .NET Script executing and debugging.

In our products and solutions we heavily rely on Microsoft compiler services to provide C#/Visual Basic scripting capabilities allowing to extend .NET applications with user-defined logic. There are certain limitations that come with this technology, the most common ones experienced by our customers are described below.

Memory consumption

In order to refer to application-defined objects .NET scripts are compiled by Microsoft .NET Compiler into .NET assemblies (dlls), and loaded into an application domain. These assemblies cannot be unloaded afterwards, which potentially could create a problems due to the application memory footprint growing if scripts are constantly updated/recompiled.

To deal with script dlls being accumulated in an application memory, scripts can be be compiled into a separate executable (or into .NET dlls loaded in a separate application domain). Then these dlls can be safely unloaded when 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 script can be executed in the separate application domain:

Script Debugging Limitations

AlterNET Script Debugger is based on the NET Framework Command-Line Debugger (mdbg), which is built on top of ICorDebug interfaces. These interfaces are included in. NET Framework and used internally by 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) and 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 a process-wide debugging, which means that a script being debugged has to run in a separate processes, otherwise debugger will freeze itself when stopping process being debugged.

This leaves two ways of incorporating .NET Script debugger into the .NET application: either Script Debugger needs to be a separate tool which can be attached to a main application process and debug .NET scripts in it; or Script debugging logic can be made a part of a main application, but then .NET scripts need to be compiled into a separate executable, which means that they can only access application-defined objects through interprocess-communication techniques (i.e. .NET remoting).
It's worth mentioning that debugging an application itself using Visual Studio and at the same time debugging scripts in this application using Script Debugger is not quite possible, as Windows supports only one debug process to be attached to the application process.

Please refer to DebugMyScript and DebugRemoteScript quick start projects that are installed as part of Extensibility Studio for details of implementing both approaches.

We believe that a power and speed of .NET run-time execution can compensate for the inconveniences related to the limitations desribed above, and running debuggers as a separate tools is not an uncommon in the industry: as an example VBA Macro execution and debugging in Microsoft Office applications are implemented as a separate tool as well. 

Having said that, we recognize that some users might need to have scripting execution and debugging to be part of the same application; in the subsequent articles we're going to blog about alternative scripting techologies allowing to implement this functionality. 

Comments (0)

    Post has no comments.

Leave a comment