Best Of

The LINQPad 9 early preview should be here within days

AFAIK, you get the same issue in Visual Studio when renaming symbols. Making refactoring work reliably across code that's excluded due to preprocessor directives is tricky, to say the least, and without Roslyn support, would be opening a can of worms. The refactoring engine would have to re-run the refactor multiple times with different combination of symbols defined and undefined, and without extensive edge-case handling, could cause spectacular failure.

Thanks - I'll get a fix into the next build.

It broke on older .NET versions. The LINQPad 8 GUI supports .NET 6 to .NET 9. The latest Roslyn package requires .NET 8+.

It shouldn't really be a problem, because LINQPad 9 will enter early preview status soon. The GUI for LINQPad 9 supports .NET 8 to 10 (scripts can run down to .NET 6). LINQPad 9 a major update that unifies the Windows & macOS codebases, and has been more than a year in the making. Stay tuned!

Sorry: it turns out the latest Roslyn assemblies are causing issues with LINQPad, and this feature has been withdrawn for now.

Preview support for this feature is now available in 8.9.3.

Done!

You're right - getting the correct logic is tricky, and I have to be extremely careful not to do anything that could change functionality for existing users.

So, for LINQPad 9, I've kept it simple and aimed for minimal disruption. This means it won't be a complete replacement for what you've done. I've improved the entry points, so instead of calling Util.InvokeScript with true and "eval", you now call Util.JS.Eval(string javaScript), or Util.JS.Run if there's no return value. (This won't conflict with your JS.* methods because it's a nested class in Util.) The old InvokeScript method is hidden, but will remain in place indefinitely for backward compatibility (there are similar changes on LINQPad's HtmlElement class). This change had to happen because in LINQPad 9, there's been a terminology change. "Queries" are now "Scripts", so a method called Util.InvokeScript to invoke JavaScript is confusing, to say the least. (Also, having to pass "eval" as a parameter has always felt yucky - it was a hangover from the original Trident implementation.) Also, Uti.JS.Eval now returns a string rather than an object - again, returning an object was a hangover from Trident.

Exception-handling uses a try/catch, with the code inside an eval, so it can catch both syntax and runtime errors. However, I'm not planning to take a dependency on the V8 engine at this stage, so the line/column info is shown only for runtime errors. Async errors are handled via window.onerror, which posts back to the WPF side. Again, there's limited stack info, but it's much better what we have now.

There will be an early LINQPad 9 beta in the next month or two. It's a major revision, with most of the UI rewritten in WPF.

Microsoft has recently released .NET 10 Preview 4, which includes a dotnet run app.cs feature. I think it's very similar to the execution environment of LINQPad. I wonder if LINQPad can provide an "Export to .NET Script" feature?

Links:

• Announcing dotnet run app.cs – A simpler way to start with C# and .NET 10
• https://github.com/dotnet/sdk/blob/main/documentation/general/dotnet-run-file.md#multiple-c-files

v8.9.2

LPRun fails with the error mentioned by OP. LPRun 5 (5.53) is OK.

LINQPad is OK.

Yes, this is OK.