To enable the Pro/Developer/Premium features of LINQPad 7, you will need to upgrade your license to Version 7 (unless you purchased recently.)
A LINQPad 7 license works for all older versions of LINQPad, too.
LINQPad 7 requires at least one of the following runtimes:
- .NET 6 (Desktop) - RC1 or later
- .NET 5 (Desktop)
- .NET 3.1 (Desktop)
If none of these have been installed, LINQPad will bootstrap the installation of .NET 6. If multiple runtimes have been installed, you can choose which to use on a per-query basis via a dropdown in the toolbar. (You can also set a global default in Edit | Preferences.)
.NET Core 3.0 is no longer supported.
The xcopy-deployable version of LINQPad 7 ships with the following launchers:
LINQPad7-x64.exe // for X64
LINQPad7-x86.exe // for X86 - choose this if you need to reference native 32-bit DLLs
LINQPad7-arm64.exe // for ARM64 machines such as Surface Pro X
It is recommended that you rename/copy the launcher that corresponds to your native platform to LINQPad7.exe.
LINQPad's launchers are custom CLR hosts. This allows them to bind the host to the optimum .NET version, and bootstrap the installation of .NET if no suitable version has been installed.
Launchers for Command-Line Support
LINQPad also ships with special new launchers for executing queries via the command-line:
LPRun7-x64.exe // X64
LPRun7-x86.exe // X86
LPRun7-arm64.exe // ARM64
It is recommended that you rename/copy the launcher that corresponds to your native platform to LPRun7.exe (the RTM installer will do this for you automatically).
These are also custom CLR hosts and include logic on the unmanaged side to determine which .NET version to spin up (new to LINQPad 7).
Instead of looking for a .runtimeconfig.json file, the command-line launchers locate and examine the .linq query that you want to run.
If you chose a specific .NET version in the toolbar when you wrote the query, this will have been saved to the .linq file, and this choice
will be honored. Otherwise the launcher parses the user-preferences file for your default framework choice.
You can also specify/override the .NET version with LPRun7's
LPRun7 -fx=6.0 (query-to-run) // Run query under .NET 6.0
LPRun7 -fx=5.0 (query-to-run) // Run query under .NET 5.0
LPRun7 -fx=3.1 (query-to-run) // Run query under .NET 3.1
LINQPad 7 natively supports the Windows ARM64 platform, for an optimized development experience on ARM64 laptops.
This includes LINQPad's debugger, which has been fully updated with ARM64 offsets and registers, so you can debug scripts just as you would on X64/X86 machines.
EF Core 6.0
LINQPad 7 supports Entity Framework Core 6.0 (as well as older versions, down to 3.0). LINQPad's EF Core driver understands the compatibility matrix between
versions/subversions of .NET and EF Core, and if necessary, will switch your query to the closest compatible .NET version (with a warning).
LINQPad 7's EF Core drivers no longer support EF Core 2.x - the minimum supported version is now EF Core 3.
DateOnly and TimeOnly Types
.NET 6 includes DateOnly and TimeOnly types to represent just a date or time. In LINQPad 7, you can control the default fomatting for these new types in Edit | Preferences > Results.
Additionally, LINQPad's internal implementation of LINQ-to-SQL has been updated to support DateOnly and TimeOnly, so you can now have a perfect mapping
for SQL Server's date and time types.
To ensure backward compatiblity, this feature is disabled on existing connections by default; to enable, tick the checkbox in the connection properties dialog.
(This feature is also disabled if you haven't installed .NET 6+.)
You can use properties of DateOnly and TimeOnly (such as Year, Month, Hour, Minute, etc.) in LINQ-to-SQL queries and these will be translated into SQL.
LINQPad's LINQ-to-SQL also includes an extension method on DateTime called DateOnly() to extract the DateOnly portion - this helps
in scenarios such as comparing a DateOnly column with a DateTime column.
Support for DateTime and TimeOnly in EF Core will arrive when this feature has been implemented by the EF Core team.
LINQPad 7's Util.Dif function now has a more powerful diffing engine that can descend into strings and identify insertions/deletions in scalar-typed lists.
This helps in scenarios such as regression testing, where you want to compare the output from old and new algorithms.
When strings are compared, a full text-diffing library is employed to show insertions and deletions:
Util.Dif ("The quick brown fox jumps over the lazy dog.",
"The quick brown fox *jumps* over the lazy dog").Dump();
The quick brown fox jumps*jumps* over the lazy dog.
LINQPad first applies a series of heuristics to determine whether to use word- or line-based chunking,
allowing the comparison to be useful in a variety of scenarios without manual input.
JsonDocument or JsonNode now render as syntax-highlighted JSON when dumped.
Calling Dump(true) results in the JSON being displayed in a separate output panel with an outlining editor (as with XDocument).
If you prefer to see the object structure with a JsonNode, you can do so by calling DumpRaw() instead of Dump().
LINQPad also lets you open .json files directly in the editor, with a toolbar option to format the document.
Running LINQPad versions side-by-side
For .NET Framework support, you can continue to run LINQPad 5 side-by-side with LINQPad 7.
(You can also run LINQPad 6 side-by-side, although there is little benefit unless you still need to support .NET 3.0 or EF Core 2.x.)
Here are some tips to help you with sharing queries between LINQPad 5 and LINQPad 7:
- Any .NET Framework assembly references are ignored in LINQPad 7.
- Other assembly references may cause difficulties unless they are to .NET Standard libraries. NuGet package references are the best option.
- For conditional compilation, the NETCORE symbol is defined in LINQPad 7 but not LINQPad 5.
My Extensions is separate for LINQPad 5 and 7, so each can have different implementations and dependencies.
As long as you provide textually similar methods in both, queries will work with both.