The compiler emits a C# script file or an executable in the same directory
and with the same file name as the source query except it bears either the
.csx or the
.exe extension. It also creates a Windows batch file
alongside that does the following:
- Checks that referenced NuGet packages are installed.
- Installs missing NuGet packages.
LINQPADLESSenvironment variable to the compiler version.
- Depending on the target output, it either invokes the C# script using
csi.exeor the executable and passes any remaining arguments.
Compile a single LINQPad query file in the current directory:
Compile all LINQPad query files:
Compile all LINQPad query files in a specific directory:
Compile all LINQPad query files in a specific directory and sub-directories within:
lpless -r C:\LINQPad\Queries\*.linq
Compile all LINQPad query files starting with
lpless -r C:\LINQPad\Queries\Foo*.linq
Compile (incremental) outdated files only:
lpless -i C:\LINQPad\Queries\Foo*.linq
Watch particular files in a directory and re-compile outdated ones on changes:
lpless -w C:\LINQPad\Queries\Foo*.linq
Foo.linq using the
FakeLinqPad package and importing
FakeLinqPad namespace (both in addition to packages and namespaces
lpless --ref FakeLinqPad --imp FakeLinqPad Foo.linq
Compile an executable:
lpless --target exe Foo.linq
For more information, see help:
Why does LINQPadless exist?
LINQPad is an excellent alternative to Visual Studio when you want to script
some code but don't want all the ceremony of a Visual Studio solution or
project. You can use NuGet packages, get the same experience as IntelliSense,
even debug through your code and all the while maintaining a single source
file. What's there not to love about it? However, when you want to ship that
code to someone or automate it, you are tied to LINQPad when that dependency
is not necessary. That's where
lpless comes in. It turns your LINQ Query
file into a C# script or an executabe that you can then run without LINQPad.
What's different from
lprun is a good solution when you need 100% compatibility and
parity with LINQPad features at run-time. On the other hand, when all you
are doing is using LINQPad as a lightweight IDE to script some task
that doesn't need its bells and whistles then turning those queries into C#
scripts or executables enables them be shipped and run without LINQPad.
LINQPad Query files must be either C# Statements, Expression or Program. In
the case of a C# Program query, a
Main declared to be asynchronous must
Extension methods are not supported at the moment.
LINQPad-specified methods like
Dump and those on its
Util class will
cause compilation errors when the compiled C# script is executed. This issue
can be addressed by using a faking/emulation library of sorts, like
When generating an executable, referenced assemblies (whether from NuGet packages or otherwise) must be placed in the same directory or sub-directories below.