.csx files: Roslyn scripting globals (`Args`) not injected, so scripts won't compile
LINQPad opens and parses .csx files, and supports the CSX-style #r "nuget: ..."
directive, so a dotnet-script file looks like it's understood. But it's compiled as a
normal C# Statements script without Roslyn's scripting globals, so any use of Args
fails with:
CS0103: The name 'Args' does not exist in the current context
In Roslyn's scripting host, Args is an instance property onMicrosoft.CodeAnalysis.Scripting.Hosting.CommandLineScriptGlobals, passed as the
globals object and bound as the script's receiver. dotnet-script uses this, so bareArgs resolves there. There's no static accessor, so nothing in the script or a
referenced library can substitute for it directly.
There's no workaround from inside LINQPad:
Environment.GetCommandLineArgs()under the GUI returns the host's command line
(LINQPad.ScriptHost.dll,*:PS, port numbers, driver names) and never contains the
script's arguments.Main(string[] args)works but requires C# Program mode, which isn't valid CSX — in a.csx, a declaredMainis just an uncalled method, since the top-level statements
are the entry point.
Request
For .csx files, put an Args in scope (an IList<string>), populated from the
command-line arguments field in Script Properties (F4 > Advanced), and from LPRun's
arguments when run via LPRun. Matching Print / PrintOptions fromCommandLineScriptGlobals would complete the surface, but Args is the one that
actually blocks scripts from compiling.
Why it matters
LINQPad is now more or less the last IDE that can debug .csx — VS Code's C# extension
dropped CSX debugging and Visual Studio's C# Interactive never really covered it. That's
a genuine niche LINQPad occupies, and this one missing symbol is what stands between it
and working.
Repro
Open any .csx containing:
Args.Dump();
CS0103 on Args.