Below is the text from the presentation from the session that Nikos did in Cologne during the XBase.Future 2017 conference.

The examples from this session are stored during the installation of X# in the folder c:\Users\Public\Documents\XSharp\Scripting.

 

Why endorse scripting?

•Dynamic behavior at runtime

oExtensibility and flexibility

oUser-defined behavior

•Platform independence

oSystem operations defined in a script

•Behavior as data

oStored in files, database, cloud

oUpdated at runtime

•Rapid prototyping

Scripting is...

•Expression evaluation

oBuilt-in interpreter

oSelf-contained functionality

oSimple expressions or full statements

•Source file(s) without a project

oSingle file (multiple sources may be loaded by a single script)

oNo need for a full IDE or SDK

oDynamic compilation without an IDE

oDefinition of complex structures, classes

X# as a scripting language

•Roslyn script engine

oC# scripting

•Standalone expressions

oNo START function

oGlobal statements, expressions

oSimilar to the macro compiler (but not the same!)

oHost object maintains state

X# as a scripting language

•Complex declarations allowed

oTypes, functions can be declared

oNo namespaces!

•External references

oLoading assemblies

oNo implicit access to host assembly

oNo isolation (e.g. separate AppDomain)

The X-Sharp interpreter (xsi.exe)

•Read-Eval-Print Loop (REPL)

•Console application

•Return values are printed to the console

oWith pretty formatting!

•Maintain context

•Declare LOCAL variables

The X-Sharp interpreter (xsi.exe)

•Can load assemblies, script files

o.PRGX extension

o#R directive

o#LOAD directive

•Can run scripts from command line

oXsi.exe <script.prgx>

•Passes command-line arguments to scripts

oXsi.exe <script.prgx> <arg> ...

Alternative ways to run scripts

•Setting xsi.exe as default app for .prgx

oAlso creates file association, but without args

oEdit file association in registry

•Manually setting file association

oassoc, ftype

•Invoking without the .prgx extension

oPATHEXT

•Run without console?

oNot possible with xsi.exe since it is a console application

Scripting internals: the submission

•Every script is compiled into a “submission”

oRoslyn terminology

•Every line given to the xsi prompt creates a new submission

oInherits previous submission

oPreviously declared variables remain visible

•Cannot be inspected directly

o“SELF” and “SUPER” are not accessible

Scripting internals: the global object

•Statements execute in the context of the global object

•Generated by xsi.exe

oInteractiveScriptGlobals class

•Provides access to command-line arguments

•Print function with pretty formatting options

Scripting internals: script declarations

•Are LOCALs declared in a script really local?

oNot when they are declared outside of a method

oThey become fields of the submission class

•What about FUNCTIONs and PROCEDUREs?

oThey become methods of the submission class

•Declared types? (CLASSes, STRUCTUREs, ENUMs)

oThey become nested types in the submission class

oNot possible to have extension methods!

Application scripting: the first steps

•Add scripting capabilities to your application!

•Reference the script hosting and code analysis assemblies

oXSharp.CodeAnalysis.dll

oXSharp.Scripting.dll

•Important namespaces

oLanguageService.CodeAnalysis.Scripting

oLanguageService.CodeAnalysis.Xsharp.Scripting

•Run a script

oXSharpScript.RunAsync("? 'HELLO'")

oCompilationErrorException is thrown if the source has errors

Problem: how to pass arguments to a script?

•Passing arguments: the globals object

•The script can access public members of the globals object

oThe type of the globals object can be custom

•An instance of the globals object can be passed to RunAsync()

oPublic fields of the globals object can be used to pass arguments to the script

oThe script will access them as variables

Problem: how to provide an API to the script?

Script API: the globals object

•Public members of the globals object are accessible by the script

oRemember: the script is compiled and executed in a different assembly in-memory!

•Not an elegant method to give access to types

oBut excellent for a function-based API

oSelf-contained, not prone to errors

•The script does not have direct access to all application types

•Not a security measure!

oThe script is run in the same AppDomain (in a dynamic assembly)

Script API: using a common assembly

•Scripts can reference assemblies

oThrough the #R directive

oThrough the options passed to the RunAsync() call

•Move functions and types that should be accessible by the script to a separate assembly

oThe assembly can then be referenced by the script

•Can be used in conjunction with the globals object

Problem: how to get results back from a script?

Script result: return value

•Scripts can return a value with a RETURN statement

o...or from a standalone expression!

oEvalAsync() returns that value

oRunAsync() returns a ScriptState object, from which the return value can also be fetched

Script result: examine script state

•Variables declared by the script can be examined

oThe ScriptState object returned by RunAsync() includes methods to examine the variables

•ScriptState.GetVariable(string name)

Advanced topics: handling errors

•Compilation errors

oCompilationErrorException thrown

oRoslyn API provides access to compilation messages

oCreate script object with XsharpScript.Create()

oCompile with script:Compile()

•Returns list of diagnostic messages

•Runtime errors

oException is thrown

•AggregateException because script is ran as a Task

•e:InnerException property contains the real exception

Advanced topics: strong-typed return value

•By default a script returns OBJECT

•Custom return type can be specified

oCreate<T>()

oRunAsync<T>()

oEvaluateAsync<T>()

Advanced topics: performance tuning

•Pre-compile scripts

oScript:Compile()

oCompiled scripts can be ran multiple times

oSimilar to macros

•Delegate can be created with script:CreateDelegate()

•Native image with ngen.exe

oSpeed-up initial compilation

o64-bit version of ngen must be used for 64-bit CLR!!!

oUseful for command-line scripts (xsi.exe)

Advanced topics: functional scripts

•A script cannot be used exactly like a function

oDoes not accept arguments

•Instead, it needs a global object instance

oIs run via a script hosting object

•Additional overhead

•But scripts can evaluate to functions!

oLamda functions or delegates as return type

Advanced topics: accessing application

•Provide a reference to current assembly inmemory

oAssembly.GetExecutingAssembly()

oDoes not work with CoreCLR

•Entities declared in current assembly can be used

oFunctions & procedures

oTypes (classes, structures, etc.)

oNamespaces

Advanced topics: support for dynamics

•Need to reference the proper assembly

oMicrosoft.Csharp.dll