CS-Script 4.8.21 requires .NET 9 runtime

[Riwerwilds]

We have .NET 8 WPF application which uses CS-Script. After updating to 4.8.21 (or newer 4.8.x) we are facing issue in test environment.

Test environment is clean Win10 IoT Enterprise and .NET 8 SDK. No other software installed. In development environment everything works without issues, because it has .NET 9 SDK installed.

In test environment we found following:
4.8.19: Works fine with .NET 8 SDK
4.8.21: Does not work without .NET 9 runtime. It requires .NET 8 SDK and .NET 9 runtime.

Error message is:
CSScriptLib.CompilerException
BUILD: error : System.Net.Sockets.SocketException (10061): No connection could be made because the target machine actively refused it. [::ffff:127.0.0.1]:17001
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
at System.Net.Sockets.TcpClient.Connect(IPEndPoint remoteEP)
at CSScriptLib.BuildServer.Request(String request, Nullable1 port) at CSScriptLib.BuildServer.SendBuildRequest(String[] args, Nullable1 port)

System.ValueTuple2[System.Byte[],System.Byte[]] CompileAssemblyFromFileBatch_with_Csc(System.String[], System.String[], System.String, Boolean, CSScriptLib.CompileInfo) at CSScriptLib.CodeDomEvaluator.CompileAssemblyFromFileBatch_with_Csc(String[] fileNames, String[] ReferencedAssemblies, String outAssembly, Boolean IncludeDebugInformation, CompileInfo info) at CSScriptLib.CodeDomEvaluator.Compile(String scriptText, String scriptFile, CompileInfo info) at CSScriptLib.EvaluatorBase1.CompileCode(String scriptText, String scriptFile, CompileInfo info)
at CSScriptLib.EvaluatorBase1.CompileCode(String scriptText) at CSScriptLib.EvaluatorBase1.LoadCode(String scriptText, Object[] args)

Then even more strange thing. If we first run application which has 4.8.19 and immediately after that the application which has 4.8.21, it works! But after computer reboot 4.8.21 version fails again.

[oleg-shilo]

The problem is caused by the use of the wrong C# compiler.

Let's reflect on it point by point:

• CS-Script nuget package is transparent to CLR version as it is compiled for netstandard2.0
• The choice of the compilation engine defines if your script execution does (or does not) depend on the SDK installed (see this section):
  • Roslyn compiler (CSScript.RoslynEvaluator) does not depend on external CLR, but limited
  • CodDeom compiler (CSScript.CodeDomEvaluator) is very flexible but depends on external SDK tools
• You are using CSScript.CodeDomEvaluator. You also let the actual C# compiler be autodetected by CS-Script runtime.
  This makes your application locate csc.exe in a different location depending on what SDK is present on the target system.
• You are also using CS-Script caching. It's an excellent option, but if it is used without a deterministic csc.exe location, it can lead to the behaviour that you described as "But after computer reboot 4.8.21 version fails again."

The solution for your problem can be as simple as setting the location of csc.exe at the start of the execution.

Globals.csc = @"C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\Roslyn\csc.exe";

The exact location of the compiler will depend on your deployment scenario.
One of the most flexible options is to include the compiler as a nugget package. IE C:\Users\usr\.nuget\packages\microsoft.net.sdk.compilers.toolset\9.0.202\csc.exe

You can also play with secondary options, but I would rather focus on Globals.csc if I were you.

evaluator.IsCachingEnabled = true;
CodeDomEvaluator.CompileOnServer = true;

[Riwerwilds]

OK, understood.

But why 4.8.19 compiler auto detect finds .NET SDK 8 and uses it and 4.8.21 does not find it? Only .NET SDK 8 is present in both cases.

[oleg-shilo]

This is a good question.
Can you check what value Globals.csc returns in these two versions?
Most likely, it will give us a clue as to why the auto assign fails.

I also have another theory to check. Can you please see if setting CodeDomEvaluator.CompileOnServer = false; addresses the problem?

[Riwerwilds]

Setting CompileOnServer = false solves the issue in 4.8.21.
Globals.CSC is "C:\Program Files\dotnet\sdk\8.0.407\Roslyn\bincore\csc.dll" in both versions.

So should we use CompileOnServer = false or is there other solutions in the future? I'm not sure how this parameter affects to the functionality.

[oleg-shilo]

Great, thank you.
It confirms that this is a deployment problem with build.dll (host application for csc.exe to speed up script compilation).
I checked, and indeed, the assembly included in the package is build for .NET9 in both cs-script nuget package folders .net8 and .net9.

This is a packaging defect that will be solved in the very next release.

In a mean time please use CompileOnServer = false. It's safe. The only impact is that, in this case, csc.exe will be executed directly but not via the preloaded host build.dll. So it will be some compilation time overhead.