Transition from .NET Framework to .NET
Note, the .NET 5 roadmap has been already achieved. But the Wiki page is kept as a historical record of the transitioning from .NET Framework to .NET.
From the beginning of .NET it every release was distributed with the full set of compilers included in the deployment of the runtime. The only exception from that was .NET for Compact Framework (if anyone remembers what it is 😄).
The idea was very clean and simple: release lifecycle of tools (SDK), runtime (CLR) and specification (C# and .NET editions) were perfectly synchronized and the variety of deployments were limited to two forms: .NET SDK and .NET Runtime. And... as usual, the idyll started its slow erosion.
The biggest impact was the release of C# 6 (2015) that signified dramatic syntactic improvements over previous versions. The problem was that MS has stopped distributing new syntax compilers with .NET and only included them with the only IDE (Visual Studio).
This has fundamentally complicated integrating C# 6 and higher syntax with any solution that uses dynamic code execution. CS-Script has solved this problem. But the solution was not elegant nor even convenient. For CLI Roslyn package was embedded in the solution distro. And for the hosted scenarios (class library) CS-Script users had to import Roslyn NuGet package. Without all these tricks CS-Script could only facilitate script execution for the syntax of C# 5 and below as it was the only syntax supported by .NET runtime out of the box.
Fortunately in 2014 an alternative .NET effort has started - .NET Core. And with .NET Core, the old model of bundling the runtime with the compiling services has been resurrected. CS-Script has made the matching move and has been additionally released in the CS-Script.Core flavor.
All good but, maintaining two independent streams targeting .NET FX and .NET Core eventually became a close to impossible task. And it is not only CS-Script but the whole .NET movement has come to the same realization. Thus, in November 2020 .NET 5 was released. It is a significant conceptual change in the .NET model. To put it simply, .NET 5 is a new name for .NET Core. And .NET FX has been effectively discontinued. While of course some maintenance releases will be published in future.
However, .NET 5 did not just outlawed .NET FX. Instead, it has provided the bridge for executing platform dependent .NET FX libraries. Thus, .NET 5 can still run WinForms and WPF. Basically, the old technologies and experiences are still allowed but they are accessible through the new modern facade.
This also means that CS-Script needs to make the matching move again. Thus, in 2020 CS-Script (.NET 5 preview) was released. The completion of the migration is planned for early 2021.
Similarly to .NET the CS-Script will effectively stop evolving its .NET FX editing and provide access to the most valuable old functionality via the current Evaluator interface that was introduced in CS-Script.Core. This means that CS-Script will support script execution on both target platforms .NET Core and .NET FX through the same codebase and the same binaries (courtesy of .NET 5 bridging).
Thus, the NuGet packages for "CS-Script.Core" will be renamed in "CS-Script" and recompiled for .NET Standard so they can be hosted in both .NET 5 and legacy .NET FX applications.
The current CS-Script codebase is to be preserved in a new repository (https://github.com/oleg-shilo/cs-script.net-framework) so if required some maintenance releases can be published. And the very current .NET5_preview branch of 'cs-script.core' will be moved to 'cs-script' repository while 'cs-script.core' repository will be decommissioned.
The development of a new converged codebase will allow CS-Script to lose some weight. It has grown quite a few features that are no longer relevant or never grew over the experimental status.
- All scripts are compiled with debug symbols generated. This has no practical impact on user experience though.
- No surrogate process support (//css_host) for x86 vs. x64 execution The CPU-specific engine host executable must be used.
- No support for deprecated settings:
- Settings.DefaultApartmentState
- Settings.UsePostProcessor
- Settings.TargetFramework
- Settings.CleanupShellCommand
- Settings.DoCleanupAfterNumberOfRuns
- No automatic elevation via arg '-elevate'. Elevation must be done via shell.
- . . .
But the most significant interface change is that CSScript.Native will no longer be available and you will have to use CSScript.Evaluator instead. This move is consistent with the message of promoting the CSScript.Evaluator is the only long term interface that is by far more beneficial than old fashioned CSScript.Native.
CSScript.Evaluator is now more than 2 years old and it is mature enough to replace the old interface.
Of course, this can impact your products/solutions. And if you do not care about C# syntax higher than C#5 you can still use the latest release of CS-Script that targets .NET FX. Otherwise, you are much better off switching to CSScript.Evaluator interface of CS-Script for .NET 5.
IMPORTANT: Please make no mistake of assuming that dropping/decommissioning CS-Script direct support for .NET FX is a pure CS-Script decision. It's not. Simply if the whole .NET movement decided to drop .NET FX and focus on a more beneficial development direction, the CS-Script has no choice but to follow the move. Which is a beneficial move anyway.
The majority of development for .NET 5 is done and the most impactful side-effect of relying on Roslyn compilers (performance) has been already fully addressed. The further release candidates will become available ~Jan 2021.