I've been using LinqPad's Dump() method from C#.
and showing HTML result using following code.
<https://gist.github.com/altrive/0ce60da4dd58a2d31f4a560c9457bd6f>
It's useful when viewing variable content without debugger.

It' works on .NET runtime, but it does't works under .NET Core runtime.
(because of WinForms/WPF/etc. dependencies exists)

I know it's difficult to LinqPad itself works under .NET Core in near future.
But is there any chance LinqPad's Dump()/Diff() components available to .NET Core?

# Possible actions
1. Remove WinForms/LinqThirdParty DLL dependencies from LinqPad's Dump() call paths
-> I don't sure it's possible or not. but It seem to works if related dependencies are propery resolved.
2. Publish Dump() related features as separate NuGet packages.
3. Open source Dump() related features codes like ExpressionFormatter
-> <https://github.com/albahari/ExpressionFormatter>

# Related Issues
- LinqPad on .NET Core
<https://linqpad.uservoice.com/forums/18302-linqpad-feature-suggestions/suggestions/16961749-linqpad-on-net-core>
- Add ability to target .NET Core
<https://linqpad.uservoice.com/forums/18302-linqpad-feature-suggestions/suggestions/17456101-add-ability-to-target-net-core>
- Make Dump() extension method available in Visual Studio
<https://linqpad.uservoice.com/forums/18302-linqpad-feature-suggestions/suggestions/447166-make-dump-extension-method-available-in-visual-s>

My suggestion is to add an optional expandable text input pane where any string could be written. This pane would be visible when choosing C# Program (or VB / F# Program) in the language drop down. The program template would then feature a Main(string arg) where the input would be fed.

Many times I find myself pasting json, xml, csv, tsv data etc into the programming pane of linqpad. Afterwards I have to put the text into a string variable and replace quoute characters and other special chars to make it compile. Sometimes I instead write the text into a file and load the file into the variable. Both solutions work and are not to hard to acheive, however it would be quicker just to paste the text into a textbox and have it readily available in the program for processing.

For me this would be a productivity feature I would use quite a lot.

The hang occurs when there is an unclosed external resource. The linqpad doesn't get stuck because it doesn't unload the application domain and therefore does not wait for the process to exit completely.

There should be some sort of a timeout for the registration of the query exited event and the finilizers to finish their job. If they don't finish in a timely manner you need to kill the process forcefully.

We were using https://github.com/sshnet/SSH.NET and didn't call .Exit() everywhere.

This produces the hang of sorts:

<Query Kind="Statements">
<Reference Relative="..\..\SSH\Renci.SshNet.dll">C:\Users\User\Desktop\SSH\Renci.SshNet.dll</Reference>
<Namespace>Renci.SshNet</Namespace>
</Query>

var sshClient = new SshClient("demo.wftpserver.com", 2222, "admin", "root");
sshClient.Connect();
var command = sshClient.RunCommand("test");
command.Result.Dump();

Then call:
lprun ssh.linq

<-- dreadful hang is right here

It is time to move to the next level: cross-server or cross-domain queries, for a truly great orchestration experience.

I have experimented with this and it's working nicely:

dynamic odata = Activator.CreateInstance(Type.GetType("LINQPad.User.DemoService, odata", true), new Uri("https://services.odata.org/V3/OData/OData.svc/"));
((object)odata.Persons).Dump();
dynamic a = Activator.CreateInstance(Type.GetType("LINQPad.User.TypedDataContext, a", true));
((object)a.Persons).Dump();
dynamic db = Activator.CreateInstance(Type.GetType("LINQPad.User.TypedDataContext, db", true));
((object)db.Products).Dump();

I'm specifically referring to this line in the FAQ (https://www.linqpad.net/FAQ.aspx):
"The databases that you query must reside on the same server."

That's a major limitation.

Possible solutions:
1. Unique data context class names in the LINQPad.User namespace.
2. `extern alias` functionality?
3. Uniquely nest all classes with respect to their connection name (for example, in the db.dll all classes will reside in LINQPad.User.db.* as opposed to the current LINQPad.User.* namespace)
4. With odata you named the resulting class DemoService, perhaps the same could be done with the sql connections