CSScriptLibrary.dll distribution for .NET 4.6 #150
Comments
|
It is a complicated topic that is a mess thanks to the years of compilers' confusion fueled by depoyment inconsistencies in various .NET distributions.
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 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. 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); |
|
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. |
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?
Thank you, the issue status was not updated even though the fix was was released. Addressed now. |
|
With "traditional" I meant a |
|
But if I indeed create And in NuGet package the assembly that gets referenced by the project in case of v4.5 and v4.6 is also the same. |
|
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... |
|
I have just searched for
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 Still, two questions remain:
And a minor inconsistency:
|
|
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 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:
I know it can be confusing... |
|
It looks like I just missed your prev post by a few hours and was answering |
That's exactly right.
Yes this file needs an update. Corrected. Will be available in the next release.
Not sure I follow. This repo contains no
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.
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).
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. |
|
See the search result list a bit further above:
Just searched throughout the v3.28.3 source code distributation ;-) |
|
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 At this moment both "CS-Script.Core" and "CS-Script" are evolving in parallel. |
|
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. |
|
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
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.
|
|
Maybe you could [Customize your pins] such that both "cs-script" and "cs-script.core" are shown. I am asking regarding "full" vs. "core" because my host application uses the CS-Script infrastructure somewhat fine granularly, as shown in the test solution uploaded to #149. I ask you to keep this in mind for the "core" variant, otherwise I will likely run into issues when trying to one day migrate from "full" to "core". Why again this fine granuar approach? Because the users of my application write their scripts be themselves, and then load and run them in my application. Many of the users are quite inexperienced programmers, my application tries to account for this as much as possible. In a year or two you will have the chance to play around yourself, I am unpatiently finalizing the cleanup of the application to eventually make it open source. |
|
Note a problem. Done. |
|
I will get at your #149 as soon as I process the backlog at WixSharp. Which has strange tendency to get refilled every day :) |
|
I have just read a little bit around .NET Core. I also think that making .NET Core the new default makes sense. However, existing WinForms applications will likely take time to get migrated onto .NET Core. Also, based on my experiences with new (=immature) frameworks, I expect that WinForms and WPF support in .NET Core 3.0 will likely be incomplete or buggy or not performing well yet. (Microsoft has announced this thus they will have a lot of pressure to release it, no matter how immature...) So I expect that .NET Core will need another year or two to finally be considered stable enough for existing WinForms and WPF applications. As a consequence, CS-Script "full" will still be needed for some more years. |
|
Spot on.
I think you are right even though I want it to be wrong :)
Yes it is the case. I am yet to test v3 but netcore 2.1 (current cs-script.core target) compilers have enormous startup overhead.
This is the only one that may be OK. As far as I understood the are not implementing but rather tunneling to the .NET full assemblies. This is the reason why it will only work on Windows. Thus it may be reasonably complete but... "win only". |
|
Hmm, given the currently 89 open issues at https://github.com/dotnet/winforms/issues and quick-browsing the captions tell me that WinForms is way away from being stable on .NET Core. The same applies to https://github.com/dotnet/wpf/issues. And yes, both will only be supported on Windows, so the whole cross-platform-benefit is for nothing. As a result, a WinForms application likely rather sticks with .NET "full" and Mono... Looks like another masterpiece of Microsoft... Who knows, maybe there will one day be a Linux and Mac port of WinForms and WPF on .NET Core, but then this will definitely be farther away than 2 years... |
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.
The text was updated successfully, but these errors were encountered: