Bunch of minor findings

[maettu-this]

Hi Oleg,

A bunch of minor findings with the latest release. Feel free to fix or ignore:

• The set of deliverables looks odd/inconsistent:
  - cs-script.win.v4.13.1.0.zip
  - cs-script-4.13.1.0.zip
  Why sometimes "." separated sometimes "-"?
  Why sometimes "v4" and sometimes just "4"?
  - CSScriptLib.v4.13.1.0.chm
  - CS-Script.4.13.1.nupkg
  Why is .nupkg called "CS-Script" rather than "CSScriptLib" as the contained assembly?
  Why is .nupkg just v.x.y (4.13.1) rather than v.x.y.z (4.13.1.0)?
• Legacy name CSScriptLibrary in two locations:
  - \src\cscs\csscript.cs line 1510
  - \src\cscs\csscript.cs line 1697
• Several outdated copyright years:
  - "2016 Oleg Shilo"
  - "2018 Oleg Shilo"
  - "2023 Oleg Shilo"
• Doesn't "CS-Script engine Class Library for .NET 5 (and higher)" contradict Release v4.8.27.0 "Restored ability to host on .NET Framework"?
• Not fully getting the "placeholder for unloadable ScriptAssemblyLoadContext" in "AppDomain.cs". A bit more background/explanation would help.

Best regards,
Matthias

[oleg-shilo]

Great. Thank you. Will go through this and provide the update or the explanations.

[oleg-shilo]

The set of deliverables looks odd/inconsistent:

Indeed, it is inconsistent.

• cs-script-4.13.1.0.zip
  Why sometimes "." separated sometimes "-"?

You probably meant cs-script_4.13-1.deb. This name is forced by Debian packaging naming convention.

Why sometimes "v4" and sometimes just "4"?
packages (just "4") are built and named by the package managers' tools and intended to be consumed by the tools. They do not allow "v"
zip/7z files are done by humans and intended for humans, so "v" is to indicate the version. Dropping it may create some confusion in cases like this: cs-script.win.net8.4.12.0.0.zip

Why is .nupkg called "CS-Script" rather than "CSScriptLib" as the contained assembly?

There is no specific strong reason except to capture the product name as the first token and the specific purpose as the second.

• cli:
  • cs-script.cli
• nuget:
  • cs-script.RoslynProvider
  • cs-script.bin

It is very similar to the other products/packages:

• cli:
  • xunit.console
• nuget:
  • xunit
  • xunit.abstractions
  • xunit.assert

Though today, I would probably make a different decision since many packages have become obsolete.
CS-Script is an adult :) It was released in 2004. At that time, the naming was actually pretty consistent:

• product: CS-Script
• namespace: CSScript
• assembly: csscript.dll
• package: CS-Script (when nuget became available)

But with the introduction of .NET Core I had to change the name of the namespace as it was too much confusion between two incompatible runtimes.

Why is .nupkg just v.x.y (4.13.1) rather than v.x.y.z (4.13.1.0)?

The version I specify in the project is a 4-parts one. But .NET packaging tooling strips the last component.

[oleg-shilo]

Several outdated copyright years:
Done. Txs for bringing it to my attention.

[oleg-shilo]

Doesn't "CS-Script engine Class Library for .NET 5 (and higher)" contradict...

Indeed, it does. But the point of the statement is that CS-Script is designed for .NET Core family. Thus, it is supported on .NET 5+.
While it's possible to host the engine on .NET Framework, it's not a primary use case, and as such, it has very limited support.

Just to reflect this in the release description, I updated it by adding Though .NET Framework support remains limited.

I also emphasised it here:

[oleg-shilo]

"AppDomain.cs". A bit more...

It was just a mistake. An empty file. I removed it now

[maettu-this]

I have downloaded to latest release and am looking into it's details. Here's my findings. Again, feel free to fix or ignore:

\src\CSScriptLib\src\CSScriptLib\CSScriptLib.csproj
\src\CSScriptLib\src\CSScriptLib\CSScriptLib.net6.csproj
<Description>CS-Script engine Class Library for .NET 5 (and higher)</Description>

Why not simply:
<Description>CS-Script engine Class Library for .NET</Description>

https://github.com/oleg-shilo/cs-script

• "Legacy .NET Framework plugins that are yet to be ported to .NET 5"
  Does this mean the plugins no longer work with the latest CS-Script?
  Or rather their code base yet is to be updated but otherwise work fine?

https://github.com/oleg-shilo/cs-script/wiki/Choosing-Compiler-Engine

• Duplicated bullet:
  Once "simply merged together" and once "simply merges". I think these bullets could be merged into a single bullet.
• I struggle with the term "multi-module scripting". After all, I can load multiple code files/modules into a single script. Would "isolated-module scripting" match better? No, sounds too much like runtime isolation. "multi-scope scripting"? "multi-namespace scripting"? "namespaced scripting"? "scoped scripting"?
• "the C-Script nuget" should be "the CS-Script NuGet".
  But actually, cannot the whole sentence be removed now that CS-Script has reenabled support for .NET Framework?
• "3 - CS-Script WinForm" should be "3 - CS-Script WinForms".
• And there are two more things on which I'd appreciate more background if possible:
  "Need SDK installed" = "yes" for CodeDom. What parts of the SDK are required? Why cannot the host app provide the required assemblies rather than having to install the SDK?
  "Namespace declarations allowed" = "no" for Roslyn. Do you know the underlying reason? It doesn't seem to make any sense, after all, a normal C# program can have namespace declarations. If you know the underlying reason, please add a footnote explaining it, or link to a Roslyn reference where this restriction is documented.

https://github.com/oleg-shilo/cs-script/wiki/Performance%2C-Caching-and-Concurrency

• "That's why caching (in hosted scenarios) is disabled by default."
  Now caching has a very different impact on Roslyn vs. CodeDom. With Roslyn the benefits are small, but with CodeDom they are huge. Would changing the default to "enabled by default" for CodeDom be an option? Or only point at this difference in the wiki?

https://github.com/oleg-shilo/cs-script/wiki/Hosting-on-.NET-Framework

• "support is somewhat limited" but to what extent? Proposing to link "limited" to https://github.com/oleg-shilo/cs-script/wiki/Hosting-on-.NET-Framework#limitations further down.
• "support is somewhat limited" but also actually also bring benefits such as support for C# 7.3+ support.
• "you will need to use CS-Script.net-framework, which is specifically designed for that" sounds like this is something still active, i.e. maintained, bugs fixed, new things coming in. But this is not the case.

https://github.com/oleg-shilo/cs-script/wiki/Hosting-on-.NET-Framework#limitations

• ".NET Framework support is not guaranteed" to me contradicts "netstandard2.0". To me https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-0#tabpanel_1_net-standard-2-0 gives that guarantee.
• Also, to me "latest version of C# is not supported" doesn't match "show the workaround". Either, the first should be "latest version of C# is not supported out-of-the-box", or the limitation is that an additional step is needed, call it "workaround" or "additional dependency".
• "IE, the code" should probably be "I.e., the code". Internet Explorer (IE) isn't meant for sure ;-)
• "pre-.Net Core" should be "pre-.NET Core".

Reflecting more on the content, I think a comparison table same as for the compiler engine would help decision making, with ".NET", ".NET Framework on CS-Script 4+" and ".NET Framework on CS-Script 3" being the columns.

https://github.com/oleg-shilo/cs-script.net-framework

• Something wrong with "copy of the repo before the product migration on .NET 5migrat"

[oleg-shilo]

Thank you for such a thorough review.
Great points. Will work on them.