help.txt

C# Script execution engine (.NET Core). Version 4.9.5.0.
Copyright (C) 2004-2023 Oleg Shilo.

Usage: cscs <switch 1> <switch 2> <file> [params] [//x]

file	Specifies name of a script file to be run.
params	Specifies optional parameters for a script file to be run.
//x	Launch debugger just before starting the script.
---------
<switch 1>

--help|-help|-? [<command>|<scope[:md]>|<-out:<file>>]
    Displays either generic or command specific help info.
    
       <command> - one of the supported CLI commands
       <scope>  
             cli    - print documentation for all CLI commands
             syntax - print the complete documentation for scripting syntax
             md     - print the documentation in GitHub markdown format
             (e.g. -help cli:md)
       <file>    - output file for the help content
    
    Reversed order of parameters for the command specific help is also acceptable. The all following argument
    combinations print the same help topic for 'cache' command:
    
       -help cache
       -? cache
       -cache help
       -cache ?

-e
    Compiles script into console application executable.
    Note this switch will force the use of dotnet compiler as csc is not capable of building executable assemblies.
    Thus //css_engine and -engine options will always be ignored.

-ew
    Compiles script into Windows application executable (applicable only on Windows).
    Note this switch will force the use of dotnet compiler as csc is not capable of building executable assemblies.
    Thus //css_engine and -engine options will always be ignored.

-rx
    Run script as an external process. This option is incompatible with VB scripts.
    This mode allows execution of the scripts that are otherwise incompatible with the runtime of the script engine (e.g.
    x86 vs x64, .NETCore vs .NETFramework).
    Note, this execution mode comes with some limitations (depending on the compilation engine):
     - csc 
       The compiled script is executed with dotnet.exe launcher (e.g. dotnet script.dll).
     - dotnet 
       The compiled script is executed directly as exe(e.g. script.exe).
     - roslyn 
       This mode is not supported as Roslyn scripts do not support static main.

-c[:<0|1>]
    Executes compiled script cache (e.g. <cache dir>/script.cs.dll) if found.
    This command improves performance by avoiding compiling the script if it was not changed since last execution.
    
       -c:1|-c  - enable caching
       -c:0     - disable caching (which might be enabled globally)

-ca
    Compiles script file into cache file (e.g. <cache dir>/script.cs.dll).

-cd
    Compiles script file into assembly (.dll) in the script folder without execution.

-check
    Checks script for errors without execution.

-proj
    Shows script 'project info' - script and all its dependencies.
    An internal-use version of this command '-proj:csproj' can be also useful for troubleshooting.

-vs <script>|-vs:init [index_of_detected_VS_executable]
    Generates .NET project file and opens it in Visual Studio.
    The path to the Visual Studio executable (devenv.exe) needs to be defined in the environment variable
    CSSCRIPT_VSEXE.
    You can let CS-Script to detect installed Visual Studio executable and interactively select the detected executable
    for integrating it with CS-Script by using -vs:init option.
    Alternatively, you can even ask to integrate the first detected executable with: 
          cscs -vs:init 0

-vscode
    Generates .NET project file and opens it in Visual Studio Code.
    The path to the Visual Studio Code executable (code.exe) needs to be defined in the environment variable
    CSSCRIPT_VSCODEEXE.

-cache[:<ls|trim|clear>]
    Performs script cache operations.
    
     ls    - lists all cache items.
     trim  - removes all abandoned cache items.
     clear - removes all cache items.

-co:<options>
    Passes compiler options directly to the language compiler (e.g. csc.exe or dotnet.exe).
    Note, some compiler options may not be compatible if they are passed to the wrong compiler executable (see compiler
    documentation). Though the fundamental switches like /platform:* are converted by CS-Script into compatible version
    between csc.exe and dotnet.exe.
    (e.g.  -co:/d:TRACE pass /d:TRACE option to C# compiler
     or    -co:/platform:x86 to produce Win32 executable)

-ng|-engine:<csc|dotnet|roslyn>
    Forces compilation to be done by one of the supported .NET engines.
      
    dotnet - dotnet.exe compiler; this is the most versatile compilation engine though it does have a startup overhead
               when running the script for the first time. It requires .NET SDK to be installed on the target system.
      
    csc   - csc.exe compiler; the fastest compiler available. It is not suitable for WPF scripts as csc.exe cannot
              compile XAML.
              The compilation is performed in the separate child process build.exe which is somewhat equivalent to
              VBCSCompiler.exe (build server) from .NET toolset. It requires .NET SDK to be installed on the target
              system.
              CS-Script communicates with build.exe build server via socket (default port 17001). You can control port
              value via the environment variable 'CSS_BUILDSERVER_CSC_PORT'
              Value csc-inproc will suppress spinning off an build server process and .NET csc.exe will be called
              directly instead. This option convenient when socket communication is undesirable for whatever reason.
              Though in this case all the performance benefits of -ng:csc will be lost and then you are better off
              using -ng:dotnet instead.
      
    roslyn - Microsoft.CodeAnalysis.CSharp.Scripting.dll compiler; this is the most portable compilation engine. It
               does not require .NET SDK being installed. Though it does have limitations (see documentation).
               The compilation is performed in the separate child process cscs (another instance of script engine) which
               is somewhat equivalent of VBCSCompiler.exe (build server) from .NET toolset.
               CS-Script communicates with cscs build server via socket (default port 17002). You can control port value
               via the environment variable 'CSS_BUILDSERVER_ROSLYN_PORT'
               Value roslyn-inproc will suppress spinning off an external process and Roslyn compiler will be hosted in
               the original process of script engine instead. This option is convenient when socket communication is
               undesirable for whatever reason. Though in this case performance will be effected on the first run of the
               script.
      
    
    (e.g. cscs -engine:dotnet sample.cs
          cscs -ng:csc sample.cs
          cscs -ng:roslyn-inproc sample.cs
          cscs -ng:roslyn sample.cs)

-s|-sample[:<C# version>]
     -s:7    - prints C# 7+ sample. Otherwise, it prints the default canonical 'Hello World' sample.
    (e.g. cscs -s:7 > sample.cs).

-new[:<type>] [<script name>]
    Creates a new script.
    Usage: -new[:<type>] [<otput file>]
          type - script template based on available types.
          output - location to place the generated script file(s).
    
    Type           Template
    ---------------------------------------------------
    console         Console script application (Default)
    console-vb      Console VB script application
    winform         Windows Forms (WinForms) script application
    winform-vb      Windows Forms (WinForms) VB script application
    wpf             WPF script application
    wpf-cm          Caliburn.Micro based WPF script application
    toplevel|top    Top-level class script application with no entry point
    toplevel-x      Top-level class script application with no entry point; an advanced CS-Script integration samples.
    cmd             Custom command script. See https://github.com./oleg-shilo/cs-script/wiki/Custom-Commands.
     
    Legacy templates:
    auto            Auto-class (classless) script application; use 'toplevel' instead
    freestyle       Freestyle (no entry point) script application; use 'toplevel' instead
     
    Examples:
        cscs -new script
        cscs -new:toplevel script.cs
        cscs -new:console console.cs
        cscs -new:winform myapp.cs
        cscs -new:wpf hello
        cscs -new:cmd -edit

-code[:show] <script code>
    Executes script code directly without using a script file.
    Sample:
     
    
    cscs -code "Console.WriteLine(Environment.UserDomainName);#nConsole.WriteLine(#''%USERNAME%#'');"
    cscs -code "using System.Linq;#nSystem.Diagnostics.Process.GetProcessesByName(''notepad'').ToList().ForEach(x =>
    x.Kill());"
    cscs -code "SetEnvironmentVariable(ntp,notepad.exe, EnvironmentVariableTarget.Machine)"
    
     
    The -code argument must be the last argument in the command. The only argument that is allowed after the <script
    code> is //x
     
    Escaping special characters sometimes can be problematic as many shells have their own techniques (e.g. PowerShell
    collapses two single quote characters) that may conflict with CS-Script escaping approach.This is the reason why
    CS-Script offers multiple escape techniques.
    It can be beneficial during the troubleshooting to use -code:show command that outputs the received CLI arguments
    and the interpreted C# code without the execution.
     
    Since command-line interface does not allow some special characters they need to be escaped.
    
    Escaped         Interpreted character
    -------------------------------------
    #n        ->    <\n>
    #r        ->    <\r>
    #''       ->    "   
    ''        ->    "   
    #         ->    "   
    n         ->    <\n>
    r         ->    <\r>
            ->    "

-wait[:prompt]
    Waits for user input after the execution before exiting.
    If specified the execution will proceed with exit only after any std input is received.
    Applicable for console mode only.
    prompt - if none specified 'Press any key to continue...' will be used

-ac|-autoclass[:<0|1|2|out>]
    Legacy command: executes scripts without class definition. Use top-level statements (C# 9) scripts instead.
    
     -ac     - enables auto-class decoration (which might be disabled globally).
     -ac:0   - disables auto-class decoration (which might be enabled globally).
     -ac:1   - same as '-ac'
     -ac:2   - same as '-ac:1' and '-ac'
     -ac:out - prints auto-class decoration for a given script file. The argument must be followed by the path to script
               file.
    
     
    Automatically generates 'static entry point' class if the script doesn't define any.
     
    
        using System;
     
        void Main()
        {
            Console.WriteLine("Hello World!");
        }
     
    
    Using an alternative 'instance entry point' is even more convenient (and reliable).
    The acceptable 'instance entry point' signatures are:
     
        void main()
        void main(string[] args)
        int main()
        int main(string[] args)
     
    Note, having any active code above entry point is acceptable though it complicates the troubleshooting if such a code
    contains errors. (see https://github.com./oleg-shilo/cs-script/wiki/CLI---User-Guide#command-auto-class)
     
    By default CS-Script decorates the script by adding a class declaration statement to the start of the script routine
    and a class closing bracket to the end. This may have an unintended effect as any class declared in the script
    becomes a 'nested class'. While it is acceptable for practically all use-cases it may be undesired for just a few
    scenarios. For example, any class containing method extensions must be a top-level static class, which conflicts with
    the auto-class decoration algorithm.
     
    The solution to this problem is to allow some user code to be protected from being included in the decorated code.
    Users can achieve this by placing '//css_ac_end' statement into the code. Any user code below this statement will be
    excluded from the decoration and stay unchanged.

---------
<switch 2>

-dbg|-d
    Forces compiler to include debug information.

-l[:<0|1>]
    'local' (makes the script directory a 'current directory'). '1' is a default value.

-v|-ver|--version [output file]
    Prints CS-Script version information.

-dbgprint[:<0:1>]
    Controls whether to enable Python-like print methods (e.g. dbg.print(DateTime.Now)).
    This setting allows controlling dynamic referencing of script engine assembly containing the implementation of
    Python-like print methods dbg.print and derived extension methods object.print() and object.dup(). While
    dbg.print is extremely useful it can and lead to some referencing challenges when the script being executed is
    referencing assemblies compiled with dbg.print already included. The simplest way to solve this problem is to
    disable the dbg.cs inclusion.
    
     -dbgprint:1   enable dbg.cs inclusion; Same as -dbgprint;
     -dbgprint:0   disable dbg.cs inclusion;

-verbose
    Prints runtime information during the script execution.
    '-verbose2' additionally echoes compiling engine (e.g. csc.dll) input and output.
    (applicable for console clients only)

-profile
    Prints script loading performance information during the script execution.

-speed
    Prints script initialization/compilation time information of the .NET compiler. 
    You can use -ng option () 
    It is a convenient way of testing performance of the .NET distribution.

-install/-uninstall
    Sets/unsets CSSCRIPT_ROOT environment variable to the location of the script engine being executed.
    This environment variable is required for integration of CS-Script with Notepad++,Sublime Text and some other
    editors, which require CS-Script installed on the host OS.
    This command is only supported on Windows

-server[:<start|stop|restart|add|remove|ping>]
    Prints the information about build server.
    Note, the server starts automatically on the script execution that is configured to use the 'csc' or 'roslyn' engine.
    Build server is a background process, which implements top loading of C# compiler csc.exe. Somewhat similar to
    VBCSCompiler.exe.
    These options are only relevant if the compiler engine is set to 'csc' or roslyn (see '-engine' command).
    Note, the build server is deployed on the first execution of the script with csc or roslyn engine.
    Though on Linux it has to be an execution with root privileges. Or you can just run sudo css -server:add.
    
     -server:start   - deploys and starts build server. Useful if you want to start the server on system startup.
     -server:stop    - stops build server
     -server:restart - restarts build server
     -server:reset   - stops, re-deploys and starts build server
     -server:add     - deploys build server
     -server:remove  - removes build server files. Useful for troubleshooting.
     -server:ping    - Pins running instance (if any) of the build server
    
    The following options are only relevant if the compiler engine is set to 'roslyn' (see '-engine' command).
    Roslyn based build server variant is much simpler so it only exposes start and stop interface.
    
     -server_r:start - deploys and starts Roslyn build server
     -server_r:stop  - stops Roslyn build server
    
    And this is how you can start and stop both Roslyn and csc build servers with a single command:
    
     -servers:start - deploys and starts both Roslyn and csc build server
     -servers:stop  - stops both Roslyn and csc build server
     -kill          - a complete equivalent of -servers:stop

-netfx
    Compile and execute the script on the latest .NET Framework compiler (csc.exe) found on the system.
    The script will be automatically executed as an external process thus the value of the -rx switchwill be ignored.

-tc
    Trace compiler input produced by CS-Script code provider CSSRoslynProvider.dll.
    It's useful when troubleshooting custom compilers (e.g. Roslyn on Linux).

-wpf[:<enable|disable|1|0>]
    Enables/disables WPF support on Windows by updating the framework name in the *.runtimeconfig.json file
    
     -wpf               - prints current enabled status
     -wpf:<enable|1>    - enables WPF support
     -wpf:<disable|0>   - disables WPF support

-config[:<option>]
    Performs various CS-Script config operations
    
     -config:none                   - ignores config file (uses default settings)
     -config:create                 - creates config file with default settings
     -config:default                - prints default config file
     -config:<raw|xml>              - prints current config file content
     -config[:ls]                   - lists/prints current config values
     -config:<name> ?               - prints help for the configuration value specified by name
     -config:get:<name>             - prints current config value
     -config::<name>                - the same as -config:get:name
     -config:set:<name>=<value>     - sets current config value
     -config:set:<name>=add:<value> - updates the current config value content by appending the specified value.
     -config:set:<name>=del:<value> - updates the current config value content by removing all occurrences of the
                                      specified value.
     -config:<file>                 - uses custom config file
    
     
    Note: The property name in -config:set and -config:set is case insensitive and can also contain '_' as a token
    separator that is ignored during property lookup.
    
    (e.g. cscs -config:none sample.cs
          cscs -config:default > css_VB.xml
          cscs -config:set:DefaultCompilerEngine=dotnet
          cscs -config:set:DefaultArguments=add:-ac
          cscs -config:set:default_arguments=del:-ac
          cscs -config:c:\cs-script\css_VB.xml sample.vb)

-out[:<file>]
    Forces the script to be compiled into a specific location.
    Used only for very fine hosting tuning.
    (e.g. cscs -out:%temp%\%pid%\sample.dll sample.cs

-r:<assembly 1>,<assembly N>
    Uses explicitly referenced assembly.
    It is required only for rare cases when namespace cannot be resolved into assembly.
    (e.g. cscs /r:myLib.dll myScript.cs).

-dir:<directory 1>,<directory N>
    Adds path(s) to the assembly probing directory list.
    You can use the reserved word 'show' as a directory name to print the configured probing directories.
    (e.g. cscs -dir:C:\MyLibraries myScript.cs; cscs -dir:show).

-precompiler[:<file 1>,<file N>]
    Specifies custom precompiler. This can be either script or assembly file.
    Alias - pc[:<file 1>,<file N>]
    If no file(s) specified prints the code template for the custom precompiler. The special value 'print' has the same
    effect (e.g. cscs -pc:print).
    There is a special reserved word 'nodefault' to be used as a file name. It instructs script engine to prevent loading
    any built-in precompilers like the one for removing shebang before the execution.
    (see https://www.cs-script.net/cs-script/help-legacy/precompilers.html)

-pvdr|-provider:<file>
    Location of the alternative/custom code provider assembly.
    Alias - pvdr:<file>
    If set it forces script engine to use an alternative code compiler.
     
    C#7 support is implemented via Roslyn based provider: '-pvdr:CSSRoslynProvider.dll'.If the switch is not specified
    CSSRoslynProvider.dll file will be use as a code provider if it is found in the same folder where the script engine
    is. Automatic CSSRoslynProvider.dll loading can be disabled with a special 'none' argument: -pvdr:none.
    (see https://www.cs-script.net/cs-script/help-legacy/help/non_cs_compilers.html)

-nuget[:restore]
    Installs new or updates existing NuGet packages. It is a very close equivalent of dotnet restore command
    
     -nuget         - prints the list of all root packages in the repository
     -nuget:restore - Downloads and installs all packages specified in the script without executing the script.
                      Effectively it is an equivalent of -check but with the forced nuget packages restore operation.
                      Using this option is an alternative to having '//css_nuget -force ...' directive in the script code
                      as it may be a more convenient way of updating packages manually instead of having them updated on
                      every script execution/recompilation.
                      You can set CSS_RESTORE_DONOT_CLEAN environment variable to disable removing temporary folders
                      created during restore operations. This can be useful for troubleshooting NuGet packages
                      restoring.
    ---------------------------------------------
    Note: A the current NuGet support model is available since v4.7.0. The old options of this -nuget command that are
    only available with the legacy NuGet support algorithm. This mode can be enabled by setting LegacyNugetSupport
    option to false: css -config:set:LegacyNugetSupport=true. Read more:
    https://github.com./oleg-shilo/cs-script/wiki/NuGet-Support
     
    Legacy CLI:
     
    -nuget[:<package|restore>]
    This command allows a lightweight management of the NuGet packages. The functionality is limited to installing,
    restoring and updating the packages.
    
     -nuget           - prints the list of all root packages in the repository
     -nuget:<package> - downloads and installs the latest version of the package(s). 
                        Wild cards can be used to update multiple packages. For example '-nuget:ServiceStack*' will
                        update all already installed ServiceStack packages.
                        You can also use the index of the package instead of its full name.
                        (Not available with new NuGet support)
     -nuget:restore   - Downloads and installs all packages specified in the script without executing the script.

-syntax
    Prints documentation for CS-Script specific C# syntax.

-commands|-cmd[:x]
    Prints list of supported commands (arguments) as well as the custom commands defined by user.
    -cmd:x - Prints detailed information of the custom commands defined by user.

-list|-ls [<kill|k> | <kill-all|ka>
    Prints list of all currently running scripts.
    If script execution tracking is undesirable you can disable it by setting DisableCSScriptProcessTracking environment
    variable to a non empty value.
     kill|k      - Allow user to select and terminate any running script.
     *           - Terminate all running scripts when 'kill' option is used.
                   (e.g. cscs -list kill * ).

---------


**************************************
CS-Script specific syntax
**************************************
 
Engine directives:
- //css_include <file>;
- //css_import <file>[, preserve_main][, rename_namespace(<oldName>, <newName>)];
- //css_nuget [-force] [-ver:<version>] package0[,package1]..[,packageN];
- //css_nuget [-noref] [-force[:delay]] [-ver:<version>] [-rt:<runtime>] [-ng:<nuget arguments>]
package0[,package1]..[,packageN];
- //css_args arg0[,arg1]..[,argN];
- //css_reference <file>;
- //css_precompiler <file 1>,<file 2>;
- //css_searchdir <directory>;
- //css_winapp
- //css_webapp
- //css_autoclass [style]
- //css_resource <file>[, <out_file>];
- //css_co <options>;
- //css_engine <csc|dotnet|roslyn>;
- //css_ignore_namespace <namespace>;
- //css_ac_end
- //css_prescript file([arg0][,arg1]..[,argN])[ignore];
- //css_postscript file([arg0][,arg1]..[,argN])[ignore];
------------------------------------
Engine directives can be controlled (enabled/disabled) with compiler conditional symbols and environment variables via
the inline #if syntax:
 

  //css_include #if DEBUG debug_utils.cs
  //css_dir #if (DEBUG) .\bin\Debug
  //css_reference #if PRODUCTION_PC d:\temp\build\certificates.dll

------------------------------------
The script engine also always defines special compiler conditional symbol CS_SCRIPT:
 

  #if CS_SCRIPT
       Console.WriteLine("Running as a script...");
  #endif

The script engine also defines another conditional symbol NETCORE to allow userto distinguish between executions under
.NET (full) and .NET Core
------------------------------------
//css_include <file>;
 
Alias - //css_inc
 
file - name of a script file to be included at compile-time.
 
This directive is available for both CLI and hosted script execution.
 
This directive is used to import/include one script into another one. It is a logical equivalent of '#include' in C++.
 
If a relative file path is specified with a single-dot prefix it will be automatically converted into the absolute path
with respect to the location of the script file containing the //css_include directive. Otherwise it will be resolved
with respect to the process current directory.
 
If for whatever reason it is preferred to always resolve path expression with respect to the parent script location you
can configure the script engine to do it with the following command:
 

   cscs -config:set:ResolveRelativeFromParentScriptLocation = true
 
 
Note, if you use a wildcard in the imported script name (e.g. ./*_build.cs) the directive will only import from the first
probing directory where the matching file(s) is found. Be careful with the wide wildcard as '*.cs' as they may lead to
unpredictable behavior. For example they may match everything from the very first probing directory, which is typically a
current directory. Using more specific wildcards is arguably more practical (e.g. 'utils/*.cs', '*Helper.cs', './*.cs')
------------------------------------
//css_import <file>[, preserve_main][, rename_namespace(<oldName>, <newName>)];
 
Alias - //css_imp
 
This is a more specialized version of the default script importing directive //css_include (//css_inc) with some extra
renaming functionality.
While //css_include simply includes a script file in the execution as is, //css_import analyzes the file being imported
and renames namespaces and static Main(...) to avoid naming collisions. Thus you should use it only if you have naming
collision problems.
 
file             - name of a script file to be imported at compile-time.
preserve_main    - do not rename 'static Main'. 
                   .NET allows only one entry point 'static Main' method per application.Thus it is a problem if the
                   primary and the imported scripts both contain 'static Main'.To avoid this the script engine searches
                   the imported script for 'static Main' method and renames it in 'i_Main' and then uses a temporary copy
                   of the processed imported script during the execution. If you need to use the imported script as is,
                   then you should use 'preserve_main' argument with the '//css_import' directive.
rename_namespace - rename namespace clause, it can appear in the directive multiple times
oldName          - name of a namespace to be renamed during importing
newName          - new name of a namespace to be renamed during importing
 
------------------------------------
 
//css_nuget [-force] [-ver:<version>] package0[,package1]..[,packageN];
 
Downloads/Installs the NuGet package. It also automatically references the downloaded package assemblies.
By default, the package is not downloaded again if it was already downloaded.
CS-Script uses dotnet.exe to manage NuGet packages. This makes the developer experience fully consistent with traditional
SW development of compiled .NET applications.

 -force - switch to force individual packages downloading even when they were already downloaded.
 -ver:<version> - switch to download/reference a specific package version.
 
 Examples: //css_nuget cs-script;
           //css_nuget -force NLog
 
--- Legacy NuGet support ---
 
Before v4.7.0 CS-SCript was relying on nuget.exe, the only option available in .NET at that time.
To allow backwards compatibility this mode is still available and it can be enabled by setting LegacyNugetSupport
configuration value option to false with css -config:set:LegacyNugetSupport=true
Read more: https://github.com./oleg-shilo/cs-script/wiki/NuGet-Support
 
Note: Legacy NuGet support is less reliable, predictable or flexible (e.g. does not support package native assets) thus
it's highly recommend that you use this mode only if you have to.
 
The legacy NuGet support CLI is somewhat different:
//css_nuget [-noref] [-force[:delay]] [-ver:<version>] [-rt:<runtime>] [-ng:<nuget arguments>]
package0[,package1]..[,packageN];
 
If no version is specified then the highest downloaded version (if any) will be used.
Referencing the downloaded packages can only handle simple dependency scenarios when all downloaded assemblies are to be
referenced.
You should use '-noref' switch and reference assemblies manually for all other cases. For example multiple assemblies
with the same file name that target different CLRs (e.g. v3.5 vs v4.0) in the same package.
Switches:
 

 -noref         - switch for individual packages if automatic referencing isn't desired.
                  You can use 'css_nuget' environment variable for further referencing package content (e.g. //css_dir
                  %css_nuget%\WixSharp\**)
                  (Not available with new NuGet support)
 -force[:delay] - switch to force individual packages downloading even when they were already downloaded.
                  You can optionally specify a delay for the next forced downloading by the number of seconds since last
                  download.
                  '-force:3600' will delay it for one hour. This option is useful for preventing frequent download
                  interruptions during active script development.
                  (Not available with new NuGet support)
 -ver:<version> - switch to download/reference a specific package version.
 -rt:<runtime>  - switch to use specific runtime binaries (e.g. '-rt:netstandard1.3').
                  (Not available with new NuGet support)
 -ng:<args>     - switch to pass nuget.exe/dotnet restore arguments for every individual package.
                  (-restore: as an alias of this switch)
 
 
Example: //css_nuget cs-script;
         //css_nuget -restore:"-v minimal" -ver:4.1.2 NLog
         //css_nuget -ver:4.1.2 -restore:"-f --no-cache" NLog
         //css_nuget -ver:"4.1.1-rc1" -rt:netstandard2.0 -ng:"-f --no-cache" NLog
 
This directive will install CS-Script NuGet package.
(see http://www.csscript.net/help/script_nugets.html)
------------------------------------
//css_args arg0[,arg1]..[,argN];
 
Embedded script arguments. Both script and engine arguments are allowed except "/noconfig" engine command switch.
 
Example: //css_args -dbg, -inmem;
This directive will always force the script engine to execute the script in debug mode.
Note: the arguments must be coma separated.
------------------------------------
//css_reference <file>;
 
Alias - //css_ref
 
file - name of the assembly file to be loaded at run-time.
This directive is used to reference assemblies required at run time.
The assembly must be in GAC, the same folder with the script file or in the 'Script Library' folders (see 'CS-Script
settings').
 
Note if you use wildcard in the referenced assembly name (e.g. socket.*.dll) the directive will only reference from the
first probing directory where the matching file(s) is found. Be careful with the wide wildcard as '*.dll' as they may
lead to unpredictable behavior. For example they may match everything from the very first probing directory, which is
typically a current directory. Using more specific wildcards is arguably more practical (e.g. 'utils/*.dll',
'*Helper.dll', './*.dll')
 
------------------------------------
//css_precompiler <file 1>,<file 2>;
 
Alias - //css_pc
 
file - name of the script or assembly file implementing precompiler.
 
This directive is used to specify the CS-Script precompilers to be loaded and exercised against script at run time just
before compiling it. Precompilers are typically used to alter the script coder before the execution. Thus CS-Script uses
built-in precompiler to decorate classless scripts executed with -autoclass switch.
(see http://www.csscript.net/help/precompilers.html
------------------------------------
//css_searchdir <directory>;
 
Alias - //css_dir
 
directory - name of the directory to be used for script and assembly probing at run-time.
 
This directive is used to extend set of search directories (script and assembly probing).
The directory name can be a wildcard based expression.In such a case all directories matching the pattern will be this
case all directories will be probed.
The special case when the path ends with '**' is reserved to indicate 'sub directories' case. Examples:

    //css_dir packages\ServiceStack*.1.0.21\lib\net40
    //css_dir packages\**

------------------------------------
//css_winapp
 
Alias - //css_winapp
 
Adds search directories required for running WinForm and WPF scripts.
Note: you need to use csws.exe engine to run WPF scripts.
Alternatively you can set environment variable 'CSS_WINAPP' to non empty value and css.exe shim will redirect the
execution to the csws.exe executable.
------------------------------------
//css_webapp
 
Alias - //css_webapp
 
Indicates that the script app needs to be compiled against Microsoft.AspNetCore.App framework.
A typical example is a WebAPI script application.
------------------------------------
//css_autoclass [style]
 
Alias - //css_ac
 
OBSOLETE, use top-class native C# 9 feature instead
Automatically generates 'static entry point' class if the script doesn't define any.
 
    //css_ac
    using System;
 
    void Main()
    {
        Console.WriteLine("Hello World!");
    }
 
Using an alternative 'instance entry point' is even more convenient (and reliable).
The acceptable 'instance entry point' signatures are:

    void main()
    void main(string[] args)
    int main()
    int main(string[] args)
 
The convention for the classless (auto-class) code structure is as follows:
 - set of 'using' statements
 - classless 'main' 
 - user code 
 - optional //css_ac_end directive
 - optional user code that is not a subject of auto-class decoration
(see https://github.com./oleg-shilo/cs-script/wiki/CLI-Script-Execution#command-auto-class)
 
A special case of auto-class use case is a free style C# code that has no entry point 'main' at all:
 
    //css_autoclass freestyle
    using System;
 
    Console.WriteLine(Environment.Version);
 
Since it's problematic to reliable auto-detect free style auto-classes, they must be defined with the special parameter
'freestyle' after the '//css_ac' directive
 
By default, CS-Script decorates the script by adding a class declaration statement to the start of the script routine and
a class-closing bracket to the end. This may have an unintended effect as any class declared in the script becomes a
'nested class'. While it is acceptable for practically all use-cases it may be undesired for just a few scenarios. For
example, any class containing method extensions must be a top-level static class, which conflicts with the auto-class
decoration algorithm.
 
An additional '//css_autoclass_end' ('//css_ac_end') directive can be used to solve this problem.
 
It's nothing else but a marker indicating the end of the code that needs to be decorated as (wrapped into) an auto-class.
This directive allows defining top level static classes in the class-less scripts, which is required for implementing
extension methods.
 
 //css_ac
 using System;
 
 void main()
 {
     ...
 }
 
 //css_ac_end
 
 static class Extensions
 {
     static public string Convert(this string text)
     {
         ...
     }
 }
 
------------------------------------
//css_resource <file>[, <out_file>];
 
Alias - //css_res
 
file     - name of the compiled resource file (.resources) to be used with the script.
             Alternatively, it can be the name of the XML resource file (.resx) that will be compiled on-fly.
out_file  - Optional name of the compiled resource file (.resources) to be generated form the .resx input.If not
             supplied then the compiled file will have the same name as the input file but the file extension '.resx'
             changed to '.resources'.
 
This directive is used to reference resource file for script.
 Example: //css_res Scripting.Form1.resources;
          //css_res Resources1.resx;
          //css_res Form1.resx, Scripting.Form1.resources;
------------------------------------
//css_co <options>;
 
options - options string.
 
This directive is used to pass compiler options string directly to the language-specific CLR compiling engine.
Note: 
- the options may not be compatible with the compiling engine of your choice (see //css_engine).Thus //css_co
/define:CS_SCRIPT will work for csc engine but will not for dotnet since it does not support /define.
- character ; in compiler options interferes with //css_... directives so try to avoid it. Thus use -d:DEBUG
-d:NET4 instead of -d:DEBUG;NET4
 Example: //css_co /d:TRACE pass /d:TRACE option to C# compiler
          //css_co /platform:x86 to produce Win32 executable
          //css_co -nullable:enable -warnaserror:nullable to enable nullable reference types.
------------------------------------
//css_engine <csc|dotnet|roslyn>;
 
Alias - //css_ng
 
This directive is used to select compiler services for building a script into an assembly.
 
 dotnet - use dotnet.exe and on-fly .NET projects.
          This is a default compiler engine that handles well even complicated heterogeneous multi-file scripts like WPF
          scripts.
 csc    - use csc.exe. 
          This compiler shows much better performance. Though it is not suitable for WPF scripts.
This feature is conceptually similar to the VBCSCompiler.exe build server, which is not available in in .NET5/.NET-Core.
Even though available on .NET-Fx (Roslyn).
          Using this option can in order of magnitude improve compilation speed. However it's not suitable for compiling
          WPF scripts because csc.exe cannot compile XAML.
          While this feature is useful it will be deprecated when .NET5+ starts distributing its own properly working
          build server VBCSCompiler.exe.
roslyn - use Microsoft.CodeAnalysis.CSharp.Scripting.dll (Roslyn). 
         This compiler shows good performance and does not require .NET SDK. Though, it is not suitable for WPF scripts.
         See [this wiki](https://github.com./oleg-shilo/cs-script/wiki/Choosing-Compiler-Engine) for details.
 
 Example: //css_engine csc
------------------------------------
//css_ignore_namespace <namespace>;
 
Alias - //css_ignore_ns
 
namespace - name of the namespace. Use '*' to completely disable namespace resolution
 
This directive is used to prevent CS-Script from resolving the referenced namespace into the assembly.
------------------------------------
//css_ac_end
 
This directive is only applicable for class-less scripts executed with '-autoclass' CLI argument. It's nothing else but a
marker indicating the end of the code that needs to be decorated as (wrapped into) an auto-class.
This directive allows achieving top-level static classes in the class-less scripts, which is required for implementing
extension methods.
 
 //css_args -autoclass
 using System;
 
 void main()
 {
     ...
 }
 
 //css_ac_end
 
 static class Extensions
 {
     static public void Convert(this string text)
     {
         ...
     }
 }
 
------------------------------------
//css_prescript file([arg0][,arg1]..[,argN])[ignore];
 
Alias - //css_pre
 
file    - script file (extension is optional)
arg0..N - script string arguments
ignore  - continue execution of the main script in case of error
 
These directives are used to execute secondary pre-execution scripts.
If $this (or $this.name) is specified as arg0..N it will be replaced at execution time with the main script full name (or
file name only).
You may find that in many cases precompilers (//css_pc and -pc) are a more powerful and flexible alternative to the
pre-execution script.
------------------------------------
//css_postscript file([arg0][,arg1]..[,argN])[ignore];
Alias - //css_post
 
file    - script file (extension is optional)
arg0..N - script string arguments
ignore  - continue execution of the main script in case of error
 
These directives are used to execute secondary post-execution scripts.
If $this (or $this.name) is specified as arg0..N it will be replaced at execution time with the main script full name (or
file name only).
 
-------------------------------------
 
Note the script engine always sets the following environment variables:
 pid                     - host processId (e.g. Environment.GetEnvironmentVariable("pid")
 CSScriptRuntime         - script engine version
 CSScriptRuntimeLocation - script engine location
 cscs_exe_dir            - script engine directory
 EntryScript             - location of the entry script
 EntryScriptAssembly     - location of the compiled script assembly
 location:<asm_hash>     - location of the compiled script assembly.
 
This variable is particularly useful as it allows finding the compiled assembly file from the inside of the script code.
Even when the script loaded in-memory (InMemoryAssembly setting) but not from the original file. (e.g. var location =
Environment.GetEnvironmentVariable("location:" + Assembly.GetExecutingAssembly().GetHashCode()); 
 
Note that the default setting of 'location:<asm_hash>' is disabled. You can enable it by setting
'CSS_SCRIPTLOCATIONREFLECTION' environment variable to non empty string.
 
The following is the optional set of environment variables that the script engine uses to improve the user experience:
 
 'CSS_NUGET' 
      location of the NuGet packages, which scripts can load/reference
 
 'CSSCRIPT_ROOT'
      script engine location. Used by the engine to locate dependencies (e.g. resgen.exe). Typically this variable is
      during the CS-Script installation.
 
 'CSSCRIPT_CONSOLE_ENCODING_OVERWRITE'
      script engine output encoding if the one from the css_confix.xml needs to be overwritten.
 
 'CSSCRIPT_INC'
      a system-wide include directory for the all frequently used user scripts.
 
 'CSSCRIPT_CSC_CMD_LOG'
      the location of the log file that will be created during the script execution with the 'csc' compiler engine.the
      file will contain the command line that is used to start csc.exe to compile the script. This behavior is useful
      for the advanced debugging scenarios. Of the environment variable is not set or the value is not a valid file path
      then no log file will be created.
 
---------
During the script execution CS-Script always injects a little object inspector class 'dbg'. This class contains static
printing methods that mimic Python's 'print()'. It is particularly useful for object inspection in the absence of a
proper debugger.
 
Examples:
  dbg.print("Now:", DateTime.Now)        - prints concatenated objects.
  dbg.print(DateTime.Now)                - prints object and values of its properties.
  dbg.printf("Now: {0}", DateTime.Now)   - formats and prints object and values of its fields and properties.
 
---------
Any directive has to be written as a single line in order to have no impact on compiling by CLI compliant compiler.It
also must be placed before any namespace or class declaration.
 
---------
Example:
 
 //css_include web_api_host.cs;
 //css_reference media_server.dll;
 //css_nuget Newtonsoft.Json;
 
 using System;
 using static dbg;
 
 class MediaServer
 {
     static void Main(string[] args)
     {
         print(args);
 
         WebApi.SimpleHost(args)
               .StartAsConosle("http://localhost:8080");
   }
 }
 
Or shorter form:
 
 //css_args -ac
 //css_inc web_api_host.cs
 //css_ref media_server.dll
 //css_nuget Newtonsoft.Json
 
 using System;
 
 void main(string[] args)
 {
     print(args);
 
     WebApi.SimpleHost(args)
           .StartAsConosle("http://localhost:8080");
 }
 
---------
 Project Website: https://github.com./oleg-shilo/cs-script