Executing Code

[RexProg]

The following issues have occurred since I upgraded cs script to version 1.7.6(The previous version I used was 1.7.4) :

1. I can't debug my code(breakpoint has no effect)
2. In the previous version, the output was displayed in the Notepad++ by pressing the F5 button but in this version is in console so when my code have an error i can't see result of exception

[oleg-shilo]

The v1.7.6 is the first Syntaxer-based version. Syntaxer is a universal self contained intellisense engine for any .NET code (C# and VB.NET). Syntaxer is using Roslyn under the hood.

This plugin version was an intermediate release required for the next step - migration to portable version (x64/x86).

I couldn't rule out that expected Syntaxer could affect some functionality but not debugging or intercepting script output. Thus I am not sure your problem is specific to the new functionality of that Release.

I don't have the opportunity to do any fixes for v1.7.6 ans the next x64 version is about to be released. Alpha release is already available. Thus I suggest that you rollback your installation to 1.7.4 and then update to the portable version when it is available.

Though I would appreciate your help in determining if our problems are in fact of a general nature. Can you please manually install the alpha release of the portable version: https://github.com/oleg-shilo/cs-script.npp/releases/tag/alpha-v1.7.7.0.

Then you you please test if you can execute simple script and see the output goes to the output window correctly. Please note that the latest Roslyn engine that CS-Script is using is horribly slow on the first startup. So you may need to wait ~5+ seconds on first execution.

[RexProg]

Hi Excuse me I returned the cs script to version 1.7.4 but there were still problems I think the problem is because of the new notepad++ version Because while upgrading cs script, I upgraded notepad++ to version 7.5.4 There seems to be an incompatibility

[oleg-shilo]

OK. Txs for the additional info. BTW I have just fixed the debugging in the alpha release so now portable plugin works. Though it was tested on Notepad++ v7.5.3 (x86) and Notepad++ v7 (x64).

[RexProg]

I finally figured out the second problem The problem was solved only by checking "Intercept StdOut" and the output was displayed in notepad++

I tried the following version https://github.com/oleg-shilo/cs-script.npp/releases/tag/alpha-v1.7.7.0 Unfortunately, I encountered an error in the run

System.IO.FileNotFoundException: Could not find file 'C:\Users\RexProg\AppData\Local\Temp\CSSCRIPT\Cache\-1697377443\test2.cs.compiled'.
File name: 'C:\Users\RexProg\AppData\Local\Temp\CSSCRIPT\Cache\-1697377443\test2.cs.compiled'
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
   at System.IO.FileStream..ctor(String path, FileMode mode)
   at csscript.MetaDataItems.StampFile(String file)
Error: Specified file could not be executed.

System.IO.FileNotFoundException: Could not find file 'C:\Users\RexProg\AppData\Local\Temp\CSSCRIPT\Cache\-1697377443\test2.cs.compiled'.
File name: 'C:\Users\RexProg\AppData\Local\Temp\CSSCRIPT\Cache\-1697377443\test2.cs.compiled'
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.File.InternalReadAllBytes(String path, Boolean checkHost)
   at csscript.RemoteExecutor.ExecuteAssembly(String filename, String[] args, SystemWideLock asmLock)
   at csscript.CSExecutor.ExecuteImpl()

[oleg-shilo]

The problem was solved only by checking "Intercept StdOut" and the output was displayed in notepad++

Thank you it makes sense. Because I have also tried the alpha-Release and it worked for the N++ v7.5.4. Thus it was pure runtime settings issue. BTW "Intercept StdOut" is checked by default so may be it was some accidental click or something...

...System.IO.FileNotFoundException: Could not find file...

I am tempted to ignore this one as it is pure cs-script error, which may (or may not) have a valid cause. But in any case it has nothing to do with the N++ plugin.

BTW the latest alpha 1.7.7.1 is ready and it has debugging working. Thus it ia a matter of only a few days before the next official release is out.

[dunha]

Hi

I'm not able to get debugging working either CS-Script 1.7.8.0 NP++ 7.5.3 x86 or 7.5.4 x64

[oleg-shilo]

Just to ensure we are talking about the same things...

This is how you invoke the debugger:

Try to repeat the same test-case and let me know the outcome.

[dunha]

Yes. It doesn't stop at the break point

[oleg-shilo]

Is anything useful in the traces:

[dunha]

Just multiple entries that the bootstrapper is loaded

[oleg-shilo]

It's not much to work with. :(

It means that from CS-Script point of view everything is normal, debugger is being started without any error.

The MS debugger (mdbg.exe) is a beast with its own mind. I can only suggest debugging the plugin. Though it may not be your cup of tee.

You can also try and see if at least mono debugger works. You can do this with VSCode+CS-Script extension.

Another point, try to install the latest complete .NET, just in case if the debugger is missing some modules.

[dunha]

I am working in a corporate environment, so installing is not possible I searched C:\ for mdbg.exe and was unable to find it, although there was an empty mdbg.exe.log which was modified today. If it's any help, we upgraded to Windows 10 late last year, and I'm not sure if it has worked since then.

[oleg-shilo]

The path is C:\Program Files\Notepad++\plugins\CSScriptNpp\Mdbg\mdbg.exe. It is the version that has been extended to work with Notepad++ (to support properties).

But... it's kind of doesn't matter since your troubleshooting abilities are limited by the environment policies.

BTW, that recorded test-case 6 messages above was done on Win10 x64 + Notepad++ x32 (and x64).

[dunha]

Yes. Silly me, I was looking in the wrong place. I've had this problem before then it was fixed for a while. It might well be my environment I'm using portable NP++ if it makes any difference. I'll try it at home later to see if it works there

[dunha]

I tried the x86 version at home and 1.7.6.0 debugger was working I manually installed 1.7.8.0 by overwriting the original I received an error message that the plugin was not compatible, and I remember getting this before, although it appeared to work, but no debugging I tried to go back to 1.7.6.0 but couldn't find a download, so I uninstalled 1.7.8.0 via the plugin manager and reinstalled the same way. When debugging I had file not found error. I checked and the mdbg folder was missing The Roslyn folder also appears to be missing from the 1.7.8.0 zip file, although the mdbg folder is there

[oleg-shilo]

Great, thank you for the info.

There are a few interesting points.

I manually installed 1.7.8.0 by overwriting the original...

This might be a problem. This way you leave the old Roslyn folder alongside with the new plugin. The clean manual install requires removing the old plugin folder. I will need to reflect this on Wiki.

It is expected Roslyn folder no longer be in the Program Files folder. Having Roslyn in this folder creates some challenges during upgrading as Roslyn needs to keep some executables running even after N++ exits.

Thus now Roslyn is deployed in C:\ProgramData\CS-Script\CSScriptNpp\1.7.8.0.

Though Mdbg supposed to be there. This one seems like a problem. I will have a look into the code for possible conditions that can lead to that.

[oleg-shilo]

Hm... Mdbg is present in both "CSScriptNpp.1.7.8.0.x64.zip" and "CSScriptNpp.1.7.8.0.x86.zip". I am not now sure how it can be missing after manual install.

Anyway... I just did yet another install with the plugin manager and it seems like now I have the same problem as you.

Actually it's a good thing. I can investigate it now. Will keep you posted

[oleg-shilo]

It looks like wrong build of css_dbg.exe was placed in the package. For some reason it fails at startup.

Repackaging seems to help. Can you please test the new package before I publish it. Install it manually but don't forget, you must use 7Zip to extract the files.

CSScriptNpp.1.7.8.1.x86.zip CSScriptNpp.1.7.8.1.x64.zip

[dunha]

Thanks for your efforts I removed Roslyn and all cssscript plugin Installed 1.7.8.1 Running classless script template Script runs fine Breakpoint at line 7 Add Console.Read() to keep console open (line 8) Console statement runs OK, but code doesn't break Debug output from debug statement line 9 is blank but still in debug mode

[oleg-shilo]

Can you do a simple experiment. Instead of placing a break point use assert.

using System;
using System.Diagnostics;

class Script
{
    [STAThread]
    static public void Main(string[] args)
    {
        Console.WriteLine("Hello World!");
        Debug.WriteLine("Hello World!");
        Debug.Assert(false);
        Console.ReadLine();
    }
}

Load the script with the code above to N++, press Alt+F5 and in the assertion dialog click 'Retry':

I expect it to break in N++:

My speculation is that breakpoint is somehow not pushed to the debugger

[dunha]

It breaks as you expected

[oleg-shilo]

Excellent. Then stick to this technique as a work around and I will investigate what prevents the breakpoint to be possessed correctly.

[dunha]

It just breaks but cannot continue debugging But that's OK, I can wait. Thanks for a great project

[Julian-A]

I also have the same problems.So, we should stick to the assert ,until the next update comes?

[oleg-shilo]

I am really puzzled abut this one. I have two machines that run the same portable N++ with the same plugin binaries. One is regularly patched and has all .NET versions present, another one is a "lesser maintained" (though it might be irrelevant).

On the first one everything works just fine. On the second one the debugger cannot stop at the first specified breakpoint. Everything else is the symptoms of this very problem. BTW from the user point of view the behavior is fully consistent with what you are describing.

After numerous experiments I have found a reliable work around. You need to break the debugger explicitly, without this it skips your all further break points.

To do that place Debugger.Break as the first statement in your app:

Start debugging as normal. F5 after it breaks on entry. In my case it processes all other breakpoints correctly.

[oleg-shilo]

I think I may have just found the problem that causes the failure to break.

@Julian-A , @dunha , can you please extract the content of the attached css_dbg.zip in the plugins\CSScriptNpp folder.

The zip file contains the pair of css_dbg.exe and css_dbg.pdb required for the debugger (mdbg.exe) to break on first breakpoint found. I have just extracted them from the old release: https://github.com/oleg-shilo/cs-script.npp/releases/download/1.7.4/CSScriptNpp.1.7.4.0.7z

My speculation is that in this pair of binaries may have been broken in some deployments. It was in my case.

Let me know if it fixed the problem.

[dunha]

Hi This works now as you suspected css_dbg.exe was present in the later versions but the pdb was missing

[oleg-shilo]

Great, thank you.

It means it is a packaging problem that is easy to fix. But... it was incredibly difficult to detect :( Thus debugger behaves as expected even in the absence of pdb in my dev environment. I cannot tell why. Either because it was the same PC that was used to build css_dbg.exe or just somehow .NET runtime is different and affects how debugger starts the execution/debugging.

I am really glad the true cause has been found.

Will do the next release asap.

[dunha]

Excellent! I had wondered about pdb files before, but was prompted to look into them a bit more after this

There is an interesting article about them here if you haven't read it, which mentions debugging on build and developer machines

Cheers

[oleg-shilo]

Done. You can try beta release now: https://github.com/oleg-shilo/cs-script.npp/releases/tag/v1.7.8.4

[dunha]

Well it does hit breakpoints but has a rather verbose output from mdbg The output below is from running the default template and halted at Console.Readline() I have replaced the domain in the path with 'domain' Note the breakpoint is not reporting a complete path, not sure about the illegal characters I found at one point the breakpoints and stepping worked but the indicator was not present, which involved a bit of guesswork. I also noticed that before when I mentioned not being able to continue debugging, but I can't repro it now

MDbg (Managed debugger) v1.0.0.0 started. Copyright (C) Microsoft Corporation. All rights reserved.

For information about commands type "help"; to exit program type "quit".

load npp.dll trying to load: d:\work\pa\programs\notepad++\plugins\csscriptnpp\mdbg\npp.dll starting npp Connected as Out.Client. Connected as In.Client. Received command: settings=>breakonexception=false|maxItemsInTooltip Received command: mo nc on Received command: run "D:\Work\pa\Programs\Notepad++\plugins\CSScrip STDOUT:STOP: Breakpoint Hit

STDOUT:located at line 15 in css_dbg.cs

Received command: breakpoint+|\domain\dfsroot\MyDocs\c3 Received command: breakpoint+|\domain\dfsroot\MyDocs\c3 Received command: breakpoint+|\domain\dfsroot\MyDocs\c3 Received command: breakpoint+|C:\Users\c3171\AppData\Local\Temp\CSSC Received command: go OnAssemblyLoadmeta=>:OnAssemblyLoad OnModuleLoadmeta=>:OnModuleLoad OnAssemblyLoadmeta=>:OnAssemblyLoad OnModuleLoadmeta=>:OnModuleLoad OnExceptionmeta=>:OnException OnException2meta=>:OnException2 OnException2meta=>:OnException2 OnAssemblyLoadmeta=>:OnAssemblyLoad OnModuleLoadmeta=>:OnModuleLoad OnExceptionmeta=>:OnException OnException2meta=>:OnException2 OnException2meta=>:OnException2 OnCreateThreadmeta=>:OnCreateThread OnAssemblyLoadmeta=>:OnAssemblyLoad OnModuleLoadmeta=>:OnModuleLoad OnUpdateModuleSymbolsmeta=>:OnUpdateModuleSymbols OnBreakpointSTDOUT:STOP: Breakpoint 4 Hit

meta=>:OnBreakpoint STDOUT:7:{

Mdbg (AnalyseExecutionPosition): Illegal characters in path.Received command: next OnStepCompletemeta=>:OnStepComplete STDOUT:8: Console.WriteLine("Hello World!");

Mdbg (AnalyseExecutionPosition): Illegal characters in path.Received command: next OnStepCompletemeta=>:OnStepComplete STDOUT:9: Debug.WriteLine("Hello World!");

Mdbg (AnalyseExecutionPosition): Illegal characters in path.Received command: next OnAssemblyLoadmeta=>:OnAssemblyLoad OnModuleLoadmeta=>:OnModuleLoad OnLogMessagemeta=>:OnLogMessage OnStepCompletemeta=>:OnStepComplete STDOUT:11: Console.ReadLine();

Mdbg (AnalyseExecutionPosition): Illegal characters in path.Received command: next

[oleg-shilo]

Thank you @dunha.

The versbose output should be hidden from user. I am sorry, I didn't noticed that the pre-release contains the debugging configuration that does not hide MS debugger (mdbg.exe) window at runtime. I assume you are observing an extra console window like below:

It's just a packaging mistake that I am going to fix it before making the public release.

Note the breakpoint is not reporting a complete path..., not sure about the illegal characters

It is expected. Mdbg.exe process only reports the first N chars of the debugging command. And the "illegal characters" are just Mdbg internal traces that is not relevant to the plugin functionality. The important thing is that the break point is fired.

...stepping worked but the indicator was not present...

This is expected to be fixed. OK, I am cautiously optimistic about that. :)

I found that (at least the current) Scintilla looses markers (break points, indicators) on the text buffer being replaced (e.g. caused by formatting). Not sure if it is the Scintilla latest thing or was always like that. The problem can lead to the list of breakpoints on N++ and on Mdbg side being out of sync. The pre-release brings the fix for loosing markers and there is a really good chance that all breakpoint visual issues will be fixed.

I mentioned not being able to continue debugging...

Yes I observed this problem before, but it's gone after proper .pdb has been deployed along with css_dbg.exe.

---

BTW thank you for the link to the PDB article. Interesting read. Though, I still it has no explanation for the observed behavior:

• On build machine Mdbg can stop on breakpoint in the assembly (dll+pdb) that is loaded by the host app (css_dbg.exe) in absence of the app pdb (css_dbg.pdb).
• However on the user machine it can stop on breakpoint only if css_dbg.pdb present.

---

Thank you for your feedback. I will be starting the public release preparations.

[Julian-A]

I put the pdb into the plugin/CSScriptNpp folder.The debugger works like it should except (as dunha said )the indicator wasn't present.Do you know why?

[oleg-shilo]

It's very hard to tell.

The plugin version that you are using had no changes in this area at all. However, the third-party Notepad++ interop has been replaced with the new one that works on both x86 and x64. This interop is responsible for interacting with Scintilla rendering engine for all visual purposes including showing markers. However I don't think this new interop is a guilty part. Strangely enough I do not see this happening on my PC.

Anyway, can you please try the whole package (https://github.com/oleg-shilo/cs-script.npp/releases/tag/v1.7.8.4), not only the pdb. There was a significant rework around the markers thus there is a good chance that "current step" marker is working now. I would appreciate if you do the test as I am reluctant to do the release until l have't try to investigate this very problem.

Thank you

[Julian-A]

The marker is still not present and and the Mdbg console window pops up along with the debug console. Other than that, everything works just as expected.

[oleg-shilo]

Hm.... Mdbg console window expected to be displayed. As I mentioned the package is not final yet. But I really hoped that the step marker would work. Well... I was wrong. I tested the latest code base on a couple PC on Win10x64 in Nppx32 and Nppx64 and could not reproduce this very problem.

Anyway I will proceed with the public release as it delivers debugging. After it's done we will see if any other users report the step marker problem and may be it will give us a hint on the cause or at least the way to reproduce it.

[Julian-A]

Don't worry about the absence of the step marker, it doesn't bother me too much. Btw, I would like to thank you for making this project. Because of CS-Script, we (owners of potato laptops) can use notepad++ along with it without the use of the heavy Visual Studio IDE. (IDE is better, sometimes)

[oleg-shilo]

You are very welcome :) I am sincerely glad CS-Script is helping people. It was the reason behind it.