Advanced hosting scenarios

There were quite a few enquirers from CS-Script.Core users about implementing scripts that interact with other scripts while hosted by the same process.

This scenario is quite common when using CS-Script for .NET not .NET Core. Thus understandable many users expect the same convenience to be available on .NET Core runtime.

Problem

Unfortunately it is more complicated under .NET Core. The reason for this is that Roslyn (the only C# compiler available for .NET Core and the very compiler CS-Script.Core is using for scripting) has some fundamental flaws. Sadly Roslyn team has made a few conceptual mistakes when designing hosting model for Roslyn compiling services:

• Problem: A user supplied C# code that is compiled and executed at runtime does not support namespace declarations.
  Impact: Users cannot use namespaces to distinguish between identically named classes.

• Problem: A user supplied C# code that is always unconditionally wrapped in the external parent class. Meaning that any class in a script is a nested class.
  Impact: Users have no full control over the naming their classes. Thus any C# routine that uses any type (e.g. class) implemented in a script must know and use the full name of the type, which is non-deterministic. Thus by default, if you define the class Printer in the script it's name after the compilation will become Submission#0+Printer. Submission#0 parent class is injected by Roslyn class.

• Problem: The default name of the parent class for your script uses illegal characters (Submission#0) that cannot be present in any C# code.
  Impact: None of the classes implemented in the script cannot be used as is in any C# code.

• Problem: A script compiled with Roslyn is not loaded from a file but a memory.
  Impact: The problem seems to be very superficial at the first side. After all CLR allows dynamic assembly loading from the memory. However the problem is a complete show stopper as Roslyn refuses compiling any script that references file-less assemblies. This is a complete mind bending architectural marvel! Roslyn refuses producing assembly that have a corresponding assembly file and yet demand that all assemblies that it references must have the assembly file available. This makes it unconditionally impossible to reference one script from another.

All these awkward decisions made an impression that Roslyn team deliberately wanted to prevent users from using scripting for anything even remotely complicated and limit scripting to primitive routines like var x = 1 + 2;. Basically the team has failed to recognise the potential of their own product (e.g. implementing plugin-based architecture) and only saw the potential of scripting for REPL-like applications.

The solution