CSScriptLibrary.dll distribution for .NET 4.6

[maettu-this]

I would like to allow my users to use property initializers in their scripts. This requires C# 6.0, which is part of .NET 4.6. However, the CSScriptLibrary.dll distribution is only available for .NET 4.5 ("\cs-script\lib\Bin\NET 4.5").

From our conversation in #51 I understand that the .NET compiler services "adhere to the host application runtime version". So I could simply set my host application to .NET 4.6 and no CSScriptLibrary.dll distribution for .NET 4.6 would be needed. But, why is there a .NET 4.5 distribution at all? What is the benefit of using the .NET 4.5 distribution over the .NET 4.0 distribution?

Choosing Compiler Engine talks about C# 6 and .NET 4.6, but again, if the .NET compiler services "adhere to the host application runtime version" why is this an issue?

Obviously I am not fully understanding some of the dependencies and consequences. I am sure you can shed some more light into the topic.

[oleg-shilo]

It is a complicated topic that is a mess thanks to the years of compilers' confusion fueled by depoyment inconsistencies in various .NET distributions.

...the CSScriptLibrary.dll distribution is only available for .NET 4.5...

Not exactly. The NuGet package is available for v4.0, 4.5 and 4.6

cs-script/Source/NuGet/CS-Script.bin.nuspec

Lines 40 to 48 in 204ebd9

	<file src="lib\net40\CSScriptLibrary.dll" target="lib\net40\CSScriptLibrary.dll" />
	<file src="lib\net40\CSScriptLibrary.xml" target="lib\net40\CSScriptLibrary.xml" />
	<file src="lib\net40\Mono.CSharp.dll" target="lib\net40\Mono.CSharp.dll" />
	<file src="lib\net45\CSScriptLibrary.dll" target="lib\net45\CSScriptLibrary.dll" />
	<file src="lib\net45\CSScriptLibrary.xml" target="lib\net45\CSScriptLibrary.xml" />
	<file src="lib\net45\Mono.CSharp.dll" target="lib\net45\Mono.CSharp.dll" />
	<file src="lib\net46\CSScriptLibrary.dll" target="lib\net46\CSScriptLibrary.dll" />
	<file src="lib\net46\CSScriptLibrary.xml" target="lib\net46\CSScriptLibrary.xml" />
	<file src="lib\net46\Mono.CSharp.dll" target="lib\net46\Mono.CSharp.dll" />

And there is a benefit that one can be confident that CSScriptLibrary.dll will not have nasty surprises like changes signatures in the BCL classes that CSScriptLibrary.dll is using. It was at least one defect reported after v4.5 CSScriptLibrary.dll was running on v4.6 CLR.

"adhere to the host application runtime version" is talking about runtime. Thus the applications compiled for .NET 4.5 and .NET4.6 are hosted by the same runtime CLR v4.0. Meaning that you are absolutely right you can "set my host application to .NET 4.6 and no CSScriptLibrary.dll distribution for .NET 4.6 would be needed".

Now about C#6. When you compile C# 4, 5, 6 or even 7 the syntax is compiled to the assembly that is compatible with your runtime. Most likely CLR 4.0.

Now about compiling specifically C#6. The only compiler for this syntax version is Roslyn.
I suggest you add cs-script NuGet package to your project. It comes with the samples and you will see the deference between CS-Script native and Evaluator interface.But basically you will be able to execute C# 6 scripts as below:

CSScript.EvaluatorConfig.Engine = EvaluatorEngine.Roslyn;

dynamic script = CSScript.Evaluator
                        .LoadCode(@"using System;
                                    public class Script
                                    {
                                        public int Index {get; set;} = 777;

                                        public int Sum(int a, int b)
                                        {
                                            Console.WriteLine(Index);
                                            return a+b;
                                        }
                                    }");

int result = script.Sum(1, 2);

[maettu-this]

I see, so for C# 6 I will have to migrate to Roslyn. This likely is going to take some time, because in my hosting application I step-by-step compile, preprocess, load, run. Why? I want the application to provide best possible information to the script writer and user. The step-by-step sequence allows my application to better locate potential issues and thus give the user better advice. (The step-by-step sequence is also visible in the #109 and #149 attached test project.)

Similar with NuGet, I will eventually consider migration to use that, but would it still be possible to also deploy the 4.6 assembly in the "traditional" way?

PS: #108 still has the [Done: waiting for release] label although released in the meantime.

[oleg-shilo]

I will eventually consider migration to use that, but would it still be possible to also deploy the 4.6 assembly in the "traditional" way?

I am not sure I follow. Can you elaborate on the "traditional way". Right now you can get the CSScriptLibrary.dll assembly either from NuGet or from this project releases page. Did you have something else in mind?

: #108 still has the [Done: waiting for release]...

Thank you, the issue status was not updated even though the fix was was released. Addressed now.

[maettu-this]

With "traditional" I meant a \NET 4.6 folder in \cs-script\lib\Bin (cs-script.7z).

[oleg-shilo]

But if I indeed create cs-script\lib\Bin\NET 4.6 then it will have the content 100% identical to cs-script\lib\Bin\NET 4.5.

And in NuGet package the assembly that gets referenced by the project in case of v4.5 and v4.6 is also the same.

[maettu-this]

I see, then I misinterpreted the "after v4.5 CSScriptLibrary.dll was running on v4.6 CLR" and the listed NuGet specs. From these two pieces of information I concluded that the v4.6 assembly differs from the v4.5 assembly.

However, when v4.5 equals v4.6, why is a different assembly than v4.0 needed at all? So we are somehow back at "why is there a .NET 4.5 distribution at all"? Obviously I stil don't get it...

[maettu-this]

I have just searched for #if net45 throughout your code, finding these occurrences:

• \CSScript\v3.28.3\cs-script-source\Source\CSScript.Core\CSScriptLib\src\CSScriptLib\CSScriptLib.Eval.Roslyn.cs(235):#if NET451
• \CSScript\v3.28.3\cs-script-source\Source\CSScriptLibrary\CSScriptLib.cs(592):#if net45
• \CSScript\v3.28.3\cs-script-source\Source\CSScriptLibrary\Evaluator.Extensions.Remote.cs(117):#if net45
• \CSScript\v3.28.3\cs-script-source\Source\CSScriptLibrary\Evaluator.Extensions.Remote.cs(427):#if net45
• \CSScript\v3.28.3\cs-script-source\Source\CSScriptLibrary\IEvaluator.cs(186):#if net45

Is this the reason you explicitly deploy v4.5 binaries? I guess so, maybe I now got it:

v4.0/v4.5/v4.6/v4.7 all use the same runtime v4.0. But the v4.5 binaries make use of framework features that are only available from v4.5, thus require to be explicitly deployed.

If this is the explanation, I think such kind of information would help in \cs-script\lib\Bin\readme.txt. Also that readme doesn't tell anything about \Linux nor \Roslyn. Alternatively, if this explanation can be found at same other location, simply link there. But at least in my case such explanation would have made things clearer.

Still, two questions remain:

• Why aren't there a v4.5.1 binaries, given Roslyn.cs(235):#if NET451?
• Why isn't there a NuGet configuration for v4.7?

And a minor inconsistency:

• Capitalized #if NET451 vs lower cased #if net45/#if net4/...
  Note that the C# standard uses upper case, see https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/preprocessor-directives/preprocessor-if.

[oleg-shilo]

Initilally when .NET 4.5 was released none of the CS-Script distros had dedicated build for it.

Simply because both 4.0 and 4.5 run on the same CLR version. However very quickly I got a defect report. Apparently one of the 4.5 standard assemblies (but not CLR itself) got a slight API modification so CSScriptLibrary.dll raising method not found runtime binding exception. In order to handle this problem I had to release special distro built for 4.5. Apparently 4.6 can run on .NET 4.5 without any problem. so I opted to not having a special distribution for it.

Thus answering your question... v4.5 and v4.6 are equal, but v4.0 and v4.5 are not. Even though they all run on the same CLR v4.0

And to make the matter completely accurate this is how the different .NET distros are compared to each other:

.NET Framework version	CLR version	Included in Visual Studio version
4.6 New features	4	2015
4.5 New features	4	2012
4 New features	4	2010
3.5 New features	2.0	2008

I know it can be confusing...

[oleg-shilo]

It looks like I just missed your prev post by a few hours and was answering I see, then I misinterpreted the "after v4.5 CSScriptLibrary.dll ... one.

[oleg-shilo]

Is this the reason you explicitly deploy v4.5 binaries? I guess so, maybe I now got it: v4.0/v4.5/v4.6/v4.7 all use the same runtime v4.0. But the v4.5 binaries make use of framework features that are only available from v4.5, thus require to be explicitly deployed.

That's exactly right.

If this is the explanation, I think such kind of information would help in \cs-script\lib\Bin\readme.txt. Also that readme doesn't tell anything about \Linux nor \Roslyn.

Yes this file needs an update. Corrected. Will be available in the next release.

Why aren't there a v4.5.1 binaries, given Roslyn.cs(235):#if NET451?

Not sure I follow. This repo contains no Roslyn.cs with such compiler condition.

Why isn't there a NuGet configuration for v4.7?

Good point. Actually NuGet spec has 4.6 config for no good reason. I will consider moving all 4.6 content into v4.5 so there will be no need for having a special config for neither 4.6 nor 4.7. Anyway VS automatically picks the latest target runtime available when you add the package.

Capitalized #if NET451 vs lower cased #if net45/#if net4/...

Actually this repo consistently uses lower case. This is to avoid confusion between built-in VS compiler constants/symbols (upper case) and user defined ones (lower case).

Note that the C# standard uses upper case, see https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/preprocessor-directives/preprocessor-if.

Not exactly. MS decided to use this naming convention but they did not define it as a standard. And I opted to a different convention for the reasons two lines above.

[maettu-this]

See the search result list a bit further above:

\CSScript\v3.28.3\cs-script-source\Source\CSScript.Core\CSScriptLib\src\CSScriptLib\CSScriptLib.Eval.Roslyn.cs(235):#if NET451

Just searched throughout the v3.28.3 source code distributation ;-)

[oleg-shilo]

Ah... this is not the code from this repo :)

It is from CS-Script.Core codebase, which is now a separate project that is to replace CS-Script eventually. You can find it here: https://github.com/oleg-shilo/cs-script.core. And I do believe that the use of compiler constants/symbols is very minimal and only limited to the built-in symbols like NET451.

At this moment both "CS-Script.Core" and "CS-Script" are evolving in parallel.

[maettu-this]

Ah, got it, the "core" variant has just recently been separated.

While I fully understand the "full" vs. "core" evolution for scripting, do you intend to also outphase the host application functionality on "full"? I guess many people use a hosted script in a "full" application, and many of those probably don't vanish in the near future. Same with my application, though I of course will also consider switching from "full" to "core" one day. But this will take time...

PS: https://github.com/oleg-shilo does not state about the "core" variant, neither about some other of your projects. An update might help users to better find the "core" variant.

[oleg-shilo]

Yep, with the arrival .NET Core 3.0 it's only logical to make "Core" a default runtime. I am delaying the final move and strong encouragement because .NET Core Roslyn is embarrassingly slow and I am just hoping that v3.0 may bring some relief (yet to be tested). But if everything goes OK CS-Script.Core should ofisially replace CS-Script (full) for both hosted and stand alone execution.

Nevertheless right now stand alone engine is available from Choco and the class library from NuGet:

https://www.nuget.org/packages/CS-Script.Core/

https://chocolatey.org/packages/cs-script.core

https://github.com/oleg-shilo does not state about the "core" variant, neither about some other of your projects. An update might help users to better find the "core" variant.

Yes, this is an unfortunate way that GitHub composes the default page for a contributor/publisher. My all ~40 projects are there, you simply need to click the "Repositories" link. But by default it only shows 6 projects.