At AlterNET Software, we empower .NET developers to extend their applications with user-defined logic through C# and Visual Basic scripting. However, it’s important to be aware of some limitations associated with this approach.
Memory сonsiderations
When .NET scripts access application-defined objects, they are compiled into .NET assemblies (DLLs). These assemblies remain loaded in memory, potentially causing memory usage to increase with frequent script updates and recompilation.
To mitigate this, consider compiling scripts into separate executables or DLLs loaded in a different application domain. These can then be unloaded once the script finishes its task. Both approaches require scripts to access application objects through interprocess communication (IPC) mechanisms like .NET remoting.
.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.
Refer to our IsloatedScript quick-start example for details on script execution in a separate application domain.
Script debugging limitations
AlterNET Script Debugger utilizes 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 operates on a process-wide level. Attempting to implement debugging within the same application process in a separate thread would lead to application freezing when trying to stop the debugging session at a breakpoint or during step-by-step execution.
To implement debugging functionality, the script being debugged must run in a separate process. This separation allows the debugger to effectively manage the debugging session without interfering with the primary application’s execution.
There are two ways to incorporate the Script Debugger into your .NET application:
Separate executable
The Script Debugger can be a separate executable that attaches to the main application process to debug scripts.
Running debuggers as separate tools is a common practice in the industry. For instance, VBA Macro debugging for Microsoft Office applications is implemented as a separate tool.
Embedded debugging logic
The main application can include the necessary script debugging logic and compile scripts into separate executables. While this provides a more integrated solution, it imposes limitations on the script’s ability to access application objects through interprocess-communication techniques.
For detailed guidance on implementing both approaches, refer to the DebugMyScript and DebugRemoteScript quick-start projects. These projects are also installed as part of AlterNET Studio.
Limitations of simultaneous debugging with Visual Studio and Script Debugger
Due to Windows operating system constraints, it’s not possible to simultaneously debug an application with Visual Studio while also using the Script Debugger to debug scripts within that same application. This limitation is imposed by Windows’ restriction on the number of debug processes that can be attached to a single application process.
Balancing limitations and benefits
While the limitations described above may present challenges, the power and speed of .NET runtime execution can often compensate for these inconveniences. By carefully considering your project’s specific needs and the trade-offs involved, you can make an informed decision about the best approach for your .NET application.
Alternatives to address in-application script debugging
We understand that some users may require script execution and debugging to be integrated within the same application. To explore alternative solutions that address this need, please refer to our other blog article related to other scripting technologies, such as Python and TypeScript. This article may offer insights into potential approaches that can achieve in-application script debugging while minimizing the limitations discussed in this blog.