"Type sharing" pattern represents the most common execution scenario. According to this pattern the host application (host) and the script have some knowledge about each other. Such knowledge is expressed in ability to pass and handle run-time objects between the host and the script in one or both directions.

During script execution the host application compiles the script into assembly on fly, loads it and calls some public method(s) of the script. This is what distinguishes this execution pattern from "isolated execution" where static void Main() is always called.

The script engine class library (CSScriptLibrary.dll) provides two classes to assist with the script hosting:

• CSScript - class for compiling scripts into assemblies

• AsmHelper - class for simplifying assembly loading/unloading. This class also assists with calling the type methods and creating the type instances. The use of this class is entirely optional because the assembly produced by CSScript is just an ordinary assembly and can be handled in numerous ways (see Reflection in MSDN).

 

Implementation of the "type sharing" pattern can be as simple as two lines of code:

Array dataList= ...
Assembly script = CSScript.Load("scripts/comparer.cs", null, true); 
IComparer customComparer = (IComparer) script.CreateInstance("DataComparer");
Array.Sort(dataList, customComparer);

or

AppData data = ...
AppDataEx newData;
AsmHelper script = new AsmHelper(CSScript.Load("scripts/datamap.cs")); 
newData = (AppDataEx)script.Invoke("DataMapper.Remap", data);

But of course the complexity may vary depending on a particular development task.

The execution flow for "type sharing" scenario is not different to any other case when an external assembly is dynamically loaded and it's methods are called. The key difference is that such assembly is created on fly from the script file. That is why execution of script shares the same logical constrains as the execution of any dynamically loaded assemblies.

Such constrains are:

• The types used in both loaded assembly and the client application have to be either:

  • "well-known" types (primitives or GAC types)

  • implemented in the assembly which is referenced in both the client application and the loaded assembly

  • implemented in the host application assembly itself or in one of its dependency assemblies when using Simplified Hosting Model

• Assembly loaded to the current application domain cannot be unloaded.
  Loading to the different  application domain can be used to make it assembly unloading possible. However, extra care should be taken in this case about types which are crossing the boundaries of application domains.
  

Again, these constrains are not specific to the CS-Script but rather inherited from the nature of interaction between any dynamically loaded assemblies with the client application under CLR.

 

In This Section

Passing "well-known" type between script and host   
Information about script execution, which involves passing objects of a primitive/GAC type between the script and the host application.

Passing custom type between script and host   
Information about script execution, which involves passing objects of a custom type between the script and the host application.

Dynamic assembly loading
Read about the ways of dynamic assembly loading. 

Simplified Hosting Model

Read about Simplified Hosting Model, which offers effortless  solution for script/assembly probing problems.