Hi there,
How do you setup a debugger to debug a script that has already been compiled and is running in another process?
My application is setup as follows:
The host application opens the script editor in a new process
The script editor process can edit, save and compile the script.
Note: The compilation is not actually done in the script editor but is instead done by calling a different library in the host application.
I have tried setting up the debugger and usingScriptDebugger.AttachToProcessAsync() whenIDebuggerUICommands.Start() is called. However, the debugger doesn't seem to attach since no breakpoints get hit even though the code is executing. I'm also listening to theDebuggerErrorOccured event but that event never fires so I'm not sure what the issue could be.
I can provide more info if needed.
Thanks,
Lasharn
Hi,
You need to specify "MyCodeModules" property in order for your breakpoints to be hit.
Please use the following code:
Debugger.AttachToProcessAsync(processID, new StartDebuggingOptions { MyCodeModules = new[] { "path/to/your/script/assembly" } }));
You can also refer to DebugMyScript/StudioDemo demo projects (see AlternetStudio/RemoteControl/RemoteControlMainForm.cs, DebugMyScript/MainForm.cs) for an example of how this can be implemented.
You need to specify "MyCodeModules" property in order for your breakpoints to be hit.
Please use the following code:
Debugger.AttachToProcessAsync(processID, new StartDebuggingOptions { MyCodeModules = new[] { "path/to/your/script/assembly" } }));
You can also refer to DebugMyScript/StudioDemo demo projects (see AlternetStudio/RemoteControl/RemoteControlMainForm.cs, DebugMyScript/MainForm.cs) for an example of how this can be implemented.
Hi Yevgeni,
I have created a small standalone application to try and demonstrate. See https://github.com/robdunbar/alternet-script-debugger
The TestApp is like our real world application, in that it runs and compiles the script. Providing a link to the source file, dll and pdb.
The TestLib is like what the "application" compiles the script into. (However there is no project file)
The ScriptDebuggerApp is our attempt to debug the script (MyClass.cs) from TestLib.dll that the "application" executes.
However when I set a breakpoint on the line 15 (Thread.Sleep) and then press the run button on TestApp, the breakpoint is not hit.
The debugger appears to attach as the Output panel records Trace.WriteLine's that are coming from our TestApp.
I feel like we're close, but am missing a step. Would you be able to review our example application? I've kept it as straightforward as I can.
Thanks, Rob
I have created a small standalone application to try and demonstrate. See https://github.com/robdunbar/alternet-script-debugger
The TestApp is like our real world application, in that it runs and compiles the script. Providing a link to the source file, dll and pdb.
The TestLib is like what the "application" compiles the script into. (However there is no project file)
The ScriptDebuggerApp is our attempt to debug the script (MyClass.cs) from TestLib.dll that the "application" executes.
However when I set a breakpoint on the line 15 (Thread.Sleep) and then press the run button on TestApp, the breakpoint is not hit.
The debugger appears to attach as the Output panel records Trace.WriteLine's that are coming from our TestApp.
I feel like we're close, but am missing a step. Would you be able to review our example application? I've kept it as straightforward as I can.
Thanks, Rob
Hi Rob,
Thank you for the sample code.
In your sample project the TestLib.dll is not built by the scripter, but by the msbuild (Visual Studio) by "statically" linking the TestApp with TestLib with
Full
They are needed because by default .NET Core will produce PDBs in new "portable" format, which is not supported by the debugger.Full will make the compiler to produce "classic" PDBs.
Having said that, the way your sample project is made you are not using the scripter to compile the assemblies. To do that you would need to add the following code:
_scriptRun.ScriptHost.GenerateModulesOnDisk = true;
_scriptRun.ScriptHost.ModulesDirectoryPath = _buildDir;
_scriptRun.ScriptHost.AssemblyFileName = Path.GetFileName(_dllFile);
These lines, however, will break the sample application as it is now, because they will make the scripter to overwrite the TestLib.dll produced by the msbuild and thus the runtime will complain about the assembly manifest mismatch on load.
In order to use the scripter to dynamically compile and run user scripts, you don't need to add reference to your script assembly and invoke the script "statically" from your application code. Instead, you need to call ScriptRun.Run or ScriptRun.RunMethod methods in order to invoke your scripts. Also in your scenario you don't need the csproj file for your script. Please consult the DebugMyScript/StudioDemo demo projects (see AlternetStudio/RemoteControl/RemoteControlMainForm.cs, DebugMyScript/MainForm.cs) for an example of how this can be implemented.
Thank you for the sample code.
In your sample project the TestLib.dll is not built by the scripter, but by the msbuild (Visual Studio) by "statically" linking the TestApp with TestLib with
They are needed because by default .NET Core will produce PDBs in new "portable" format, which is not supported by the debugger.
Having said that, the way your sample project is made you are not using the scripter to compile the assemblies. To do that you would need to add the following code:
_scriptRun.ScriptHost.GenerateModulesOnDisk = true;
_scriptRun.ScriptHost.ModulesDirectoryPath = _buildDir;
_scriptRun.ScriptHost.AssemblyFileName = Path.GetFileName(_dllFile);
These lines, however, will break the sample application as it is now, because they will make the scripter to overwrite the TestLib.dll produced by the msbuild and thus the runtime will complain about the assembly manifest mismatch on load.
In order to use the scripter to dynamically compile and run user scripts, you don't need to add reference to your script assembly and invoke the script "statically" from your application code. Instead, you need to call ScriptRun.Run or ScriptRun.RunMethod methods in order to invoke your scripts. Also in your scenario you don't need the csproj file for your script. Please consult the DebugMyScript/StudioDemo demo projects (see AlternetStudio/RemoteControl/RemoteControlMainForm.cs, DebugMyScript/MainForm.cs) for an example of how this can be implemented.
1 Like
Hi Yevgeni,
Sorry about the delay in responding, I must have imagined doing so. Anyways, thanks for your feedback, changing to Full debug seemed to do the trick.
Some background, for our script editor application we have no control the dll’s compilation and so am unable to use the Alternet ScriptRunner to make everything work easily
Instead we have to send instructions to update source code + references to the “server/c++ application”, where it will compile the script and create a new dll. We then send an instruction to run the script, and then the server executes it.
Looks like I was premature in saying that all was well. When I remove all references to my .cs file and use a string for the source code instead, then application being debugged “freezes completely” once I add a breakpoint.
“Freezes completely” = Does not show as “Not Responding”. Background thread stops writing to a log file.
And having re-read your explanation, I’ll continue to investigate what my options are…
I have re-read the DebugRemoteScript, however the sample project
- Compiles its own dll
- Uses scriptRun.RunProcess opposed to attaching to an already running process.
For my situation, the remote process does the compiling and controls when the script is executed.
I have updated the sample app to more closely resemble our server, i.e. removed the static linking and use dynamic loading/unloading of the plugin. I can now debug successfully after manually attaching. And can manually save the script, recompile, reattach and debug.
I am now trying to override the DefaultDebuggerUICommands.Start method, to “auto” attach to my process, instead of the user manually having to press attach. But I am running into some trouble when using the _debugger.AttachToProcessAsync(_runtimeServerProcessId); from outside of a button click.
The relevant code is ScriptDebuggerApp.BtnAttachDebugger_Click (line 116) vs AutoAttachDebuggerUICommands.Start (line 26).
Happy to open a new issue for calling _debugger.AttachToProcessAsync(_runtimeServerProcessId); from a separate thread.
Thanks,
Rob
Hi,
If I understood you correctly, you are having some issues with attaching debugger to process. Is that issue reproducible on our samples? If not, please consider sending us a sample project that helps to reproduce the issue. In any case, please describe the problem in the following format:
Exact steps to reproduce the problem
- …
- …
Expected behavior
Actual behavior