Closed windhuan closed 3 years ago
can you provide your "Untitled-1.cs" content?
I use the default code
using System; class Script { static void Main(string[] args) { Console.WriteLine("Hello..."); } }
And can you please try executing mono cscs.exe <script file>
outside of VSCode?
Yes, the same error. but i use the mono csc.exe build it and run ,it's ok
What version of mono are you using?
OK, I am using 5.0.1 on Windows. I will need to update and check if mono has changed the location of the compiler in the new version.
The problem is that MS/Mono have stopped updating Microsoft.CodeDom.Providers.DotNetCompilerPlatform.Compiler
long time ago and I had to patch the last published build by myself. Quite possibly the patch needs the adjustment.
Making the issue into a defect...
OK , i'm using the windows version now.
And the result? The same?
It's OK on windows.
Can you please search your mono dirs on osx fo csc.exe. There can be a few of them.
I only installed the mono once .
I only installed the mono once .
Does not matter, any .NET installation including mono may have multiple compilers present for different C# syntax. But most likely it' only one.
Anyway if you provide me the location of the csec.exe I can give you a patch to try it on osx.
you can also try to set CSSCRIPT_ROSLYN
envar to the dir where "csc.exe" is just before executing "mono cscs.exe script" this may jut get you through.
The same error. this is my css_config.mono.xml content
The same error . this is my css_config.mono.xml
I am not sure why closed the issue. Is it resolved now? I am reopening it and will verify the extension works with the latest Mono. Though I can only test on Win and Linux.
One other thing... you can remove the UseAlternativeCompiler
value from the config file and this will default to the whatever compiler engine mono has by default. This may help though the supported C# syntax may fall back to C# 6 if the engine does not support C# 7.
The same error
The same error
Not sure your change had an effect.
Microsoft.CodeDom.Providers.DotNetCompilerPlatform.Compiler+MonoExecutor_patched
is a method that I have implemented in the 'alternative compiler' (CSSRoslynProvider.dll
) thus I would expect no error or a different one. But if the error is "the same" then the 'alternative compiler' is still loaded at runtime.
This is how you can check if the the removal of useAlternativeCompiler
takes the effect:
With an alternative compiler:
<useAlternativeCompiler>CSSRoslynProvider.dll</useAlternativeCompiler>
Without an alternative compiler:
<!-- <useAlternativeCompiler>CSSRoslynProvider.dll</useAlternativeCompiler> -->
Just tested on Linux Mint with Mono 5.12.0. Works as expected. I don't have xos for testing so I cannot verify/test the problem. I'll keep the issue open so if other users experience the same problem it can be revisited.
Same problem on Mac OS:
[Running] mono "/Users/michal/Library/Application Support/Code/User/cs-script.user/cscs.exe" "/Users/michal/Downloads/test.cs"
Error: Specified file could not be compiled.
System.InvalidOperationException: No process is associated with this object.
at System.Diagnostics.Process.EnsureState (System.Diagnostics.Process+State state) [0x00018] in <81ba78c8dc794b7f9f7b530c53db0f84>:0
at System.Diagnostics.Process.get_HasExited () [0x0000b] in <81ba78c8dc794b7f9f7b530c53db0f84>:0
at System.Diagnostics.Process.EnsureState (System.Diagnostics.Process+State state) [0x0007b] in <81ba78c8dc794b7f9f7b530c53db0f84>:0
at System.Diagnostics.Process.get_ExitCode () [0x00000] in <81ba78c8dc794b7f9f7b530c53db0f84>:0
at (wrapper remoting-invoke-with-check) System.Diagnostics.Process.get_ExitCode()
at Microsoft.CodeDom.Providers.DotNetCompilerPlatform.Compiler+MonoExecutor_patched.Local_InternalExecWaitWithCapture (System.String file, System.String cmd, System.String currentDir, System.CodeDom.Compiler.TempFileCollection tempFiles, System.String& outputName, System.String& errorName) [0x0011f] in <864b15734bd0484490a76fff76589a6c>:0
at Microsoft.CodeDom.Providers.DotNetCompilerPlatform.Compiler.Compile (System.CodeDom.Compiler.CompilerParameters options, System.String compilerFullPath, System.String arguments, System.String& outputFile, System.Int32& nativeReturnValue) [0x000e1] in <864b15734bd0484490a76fff76589a6c>:0
at Microsoft.CodeDom.Providers.DotNetCompilerPlatform.Compiler.FromFileBatch (System.CodeDom.Compiler.CompilerParameters options, System.String[] fileNames) [0x001b8] in <864b15734bd0484490a76fff76589a6c>:0
at Microsoft.CodeDom.Providers.DotNetCompilerPlatform.Compiler.CompileAssemblyFromFileBatch (System.CodeDom.Compiler.CompilerParameters options, System.String[] fileNames) [0x0005d] in <864b15734bd0484490a76fff76589a6c>:0
at csscript.CSExecutor.CompileAssembly (System.CodeDom.Compiler.ICodeCompiler compiler, System.CodeDom.Compiler.CompilerParameters compilerParams, System.String[] filesToCompile) [0x00000] in <c2f207e071434b87998d9f8f5c48a9bb>:0
at csscript.CSExecutor.Compile (System.String scriptFileName) [0x007d8] in <c2f207e071434b87998d9f8f5c48a9bb>:0
at csscript.CSExecutor.ExecuteImpl () [0x005a1] in <c2f207e071434b87998d9f8f5c48a9bb>:0
[Done] exited with code=1 in 0.314 seconds
On Windows works fine.
Can you please check that your config file in /Users/michal/Library/Application Support/Code/User/cs-script.user/css_config*.xml
has useAlternativeCompiler
element empty or commented out. This will force fallback to default mono C# syntax 6.0.
<useAlternativeCompiler></useAlternativeCompiler>
I change it from:
<useAlternativeCompiler>CSSRoslynProvider.dll</useAlternativeCompiler>
to
<useAlternativeCompiler></useAlternativeCompiler>
but it not helps. Still same error. And after some run attempts I get message "CS-Script is busy".
Sorry,I did not get notification about your latest post and only found it because someone else has asked the same question in another thread.
The last test you have done confirmed something that I was afraid of. The Mono distro for MacOS that you are using has changed the implementation of the default compiler-as-service interface and it doesn't longer work. I can tell this simply because "alternative compiler" (CS-Script component) did some tricky stuff that can potentially fail on new OS. But when we fall back to the default compiler it's only Mono who does the compilation and CS-Script does not do any trickery at all.
I still cannot exclude that there is some possible work around but I my options are very limited as I have no access to MacOS but Win and Linux only.
I know it's not the answer you were hoping for :(
Though I can tell you this. I am in process of rereleasing CS-Script as CS-Script.Core that targets .NET Core. In fact the engine has been already migrated and released: https://github.com/oleg-shilo/cs-script.core
And I am a few months away from migrating the all three major editors plugins on .NET Core as well (Notepad++, Sublime Text 3 and VSCode). I expect .NET Core migration to address this issue.
I have two macbooks at home. 1 is working fine. I am setting it up on my new laptop & Its giving this error. I cross-checked and confirmed, same version of MONO as well as cs-script on both.
oleg, I don't have Windows to build your code. I think , if we just produce another debug build with exception tracers that might help.
Excellent, I will prepare some special builds and send it to you for testing. Really appreciate you assistance
something in the very beginning gives this error as well in VSCode. In my older Mac I don't see this error prompt (this is the setup where everything works absolutely fine). Looks to me both could related.
Please find the attached zip file.
It contains tree test cases:
Please execute one by one all three batch files content from the root folder. It will help me to understand if the problem is caused by Mono itself, CS-Script mono integration or VSCode internals.
Thank you.
I also noticed recently the "File is a directory" error. Not sure what extension is reporting it. Do you think that it is cs-script?
OK, found it "Unable to open" is indeed triggered by CS-Script. Too bad VSCode does not show what extension has triggered the problem.
It seems like VSCode has changed the imlementation of "vscode.open" command and now it is causing error message if file
is empty (e.g. cs-script default startup action).
commands.executeCommand("vscode.open", Uri.file(file));
And previously VS code just swallowed the error silently.
Anyway, it is a CS-Script problem and an easy one to fix. I will try to publish the fix tomorrow.
Thank you for pointing me to the right direction.
I changed the cmd to .sh and ran. ALL three of them work.
So I took the testing to next step and copied it into extensions of VSCode - UNfortunately it failed again.
But good that we now have .netCore version of it
I think , I have found the real issue. Its CSSRoslynProvider.dll. Whether you specify it in config.xml or not, if it is next to cscs.exe, it is always getting picked.
Just rename/delete the dll & now, even existing CSscript extension works !!!!
This is rather excellent result.
Testing the script execution with CSSRoslynProvider.dll
was the very next thing I was planing to ask you to do. 👍
About CSSRoslynProvider.dll... The default copmiler-as-service on .NET only targets C#4 and on Mono - C#6. Both MS and Mono teams failed to extend this interface to support C7 and higher. CSSRoslynProvider.dll is a custom build of the copmiler-as-service that tunnels the compilation to Roslyn so C#7 syntax can be supported.
CSSRoslynProvider.dll is an extremely aggressive, reverse engineered, Reflection-based hack of the original copmiler-as-service implementation. I have done it as it was the only way to support C#7. And... as with any hack it only works until it stops :) Your experiments completely confirm that this hack no longer works on MacOS+Mono.
This leaves me no choice but to adjust the VSCode extension to fall back to C#6.0 on MackOS+Mono syntax.
I really appreciate your assistance as it brings the clarity.
And I see .NET Core as the only long term solution even though I am sure another Mono hack is possible. :)
Just rename/delete the dll & now, even existing CSscript extension works !!!!
That's excellent. But... there is a more constructive solution for that :)
I would like you to conduct the final experiment for me please. I want to test that "constructive solution" before I release it.
Please restore the original CSSRoslynProvider.dll and alter both of your /Users/<user>/Library/Application Support/Code/User/cs-script.user/css_config*.xml
files by replacing:
<useAlternativeCompiler></useAlternativeCompiler>
with
<useAlternativeCompiler>none</useAlternativeCompiler>
.
This should disable loading CSSRoslynProvider.dll but in a more manageable way.
You can bring both files to edit by executing "Engine settings" command:
Tank you, Oleg
setting 'none' works as well.
Excellent. Txs. Will do the release today.
Done. Please update to v1.5.9.
Thank you for your assistance with fixing this.
osx version 10.13.5 mono version 5.12.0
[Running] mono "/Users/wind/Library/Application Support/Code/User/cs-script.user/cscs.exe" "/Users/wind/Documents/test/Untitled-1.cs" Error: Specified file could not be compiled.
System.InvalidOperationException: No process is associated with this object. at System.Diagnostics.Process.EnsureState (System.Diagnostics.Process+State state) [0x00018] in <81ba78c8dc794b7f9f7b530c53db0f84>:0 at System.Diagnostics.Process.get_HasExited () [0x0000b] in <81ba78c8dc794b7f9f7b530c53db0f84>:0 at System.Diagnostics.Process.EnsureState (System.Diagnostics.Process+State state) [0x0007b] in <81ba78c8dc794b7f9f7b530c53db0f84>:0 at System.Diagnostics.Process.get_ExitCode () [0x00000] in <81ba78c8dc794b7f9f7b530c53db0f84>:0 at (wrapper remoting-invoke-with-check) System.Diagnostics.Process.get_ExitCode() at Microsoft.CodeDom.Providers.DotNetCompilerPlatform.Compiler+MonoExecutor_patched.Local_InternalExecWaitWithCapture (System.String file, System.String cmd, System.String currentDir, System.CodeDom.Compiler.TempFileCollection tempFiles, System.String& outputName, System.String& errorName) [0x0011f] in <864b15734bd0484490a76fff76589a6c>:0 at Microsoft.CodeDom.Providers.DotNetCompilerPlatform.Compiler.Compile (System.CodeDom.Compiler.CompilerParameters options, System.String compilerFullPath, System.String arguments, System.String& outputFile, System.Int32& nativeReturnValue) [0x000e1] in <864b15734bd0484490a76fff76589a6c>:0 at Microsoft.CodeDom.Providers.DotNetCompilerPlatform.Compiler.FromFileBatch (System.CodeDom.Compiler.CompilerParameters options, System.String[] fileNames) [0x001b8] in <864b15734bd0484490a76fff76589a6c>:0 at Microsoft.CodeDom.Providers.DotNetCompilerPlatform.Compiler.CompileAssemblyFromFileBatch (System.CodeDom.Compiler.CompilerParameters options, System.String[] fileNames) [0x0005d] in <864b15734bd0484490a76fff76589a6c>:0 at csscript.CSExecutor.CompileAssembly (System.CodeDom.Compiler.ICodeCompiler compiler, System.CodeDom.Compiler.CompilerParameters compilerParams, System.String[] filesToCompile) [0x00000] in <8c9ac531470d4f7d8dc846a682dcb1ef>:0 at csscript.CSExecutor.Compile (System.String scriptFileName) [0x007d8] in <8c9ac531470d4f7d8dc846a682dcb1ef>:0 at csscript.CSExecutor.ExecuteImpl () [0x005a1] in <8c9ac531470d4f7d8dc846a682dcb1ef>:0
[Done] exited with code=1 in 0.445 seconds