Any interest to support C# script ".csx" file extension?

sdflysha

There is a .csx editor: RoslynPad, seems pretty powerful, and which is open source, cross-platform and .NET Core supported, compile-to-dll supported:
https://github.com/aelij/RoslynPad

The ".csx" file format also supports reference to library/nuget, support reference to another .csx file, this is what LINQPad not supported. (And yes .csx file does not support LINQPad-like database driver and powerful Util.Xyz/.Dump function:) )

Does LINQPad has any interest or plan to take a look (or support) the ".csx" file format like RoslynPad?

JoeAlbahari

I might look into it once LINQPad 6 has been released.

Allowing #include, though, will play havoc with tooling, exception reporting & debugging.

jamesmanning

@JoeAlbahari whether its .csx or .linq or .cs or whatever, at least for me it'd be great to be able to 'add reference' to something that was C# source instead of having either having to 'pollute' all queries (My Extensions or plugins) or build a dll and put it somewhere then have the relevant subset of queries choose to reference it.

From the perspective of linqpad-scripts reuse, I just want to build able to treat a piece of C# source as a class library but without me having to go through the ceremony of making a C# project just to build the source into a .net standard 2.0 (or whatever) target.

My current 'workaround' is a separate set of projects that all have a post-build step that copy the output into a linqpad/lib folder (so lib is a peer of plugins/queries/snippets/etc) and then the queries reference the dlls in lib as needed. It's annoying having to open and rebuild the project in VS when updating, but it's working out ok for now. More 'built-in' support for 'magically treat this C# source as a class library' would be wonderful, though.

JoeAlbahari

If LINQPad allowed a #load option, but with only one level of depth (no nested #loads), would that be helpful in your scenario?

jamesmanning

#load of .csx files? or something else? Being able to #load .csx files would be great if you think in the long term we could eventually potentially get to 'full' scriptcs/csx/csi.exe kinds of support (or at least start down that path) so we could start more easily leveraging that ecosystem from linqpad.

If it's #load of something else then it might make more sense to be a kind of f4-based reference just to keep from confusing people also used to csx/scriptcs and that load.

Certainly there are viable workarounds, so I'm sure there's much more important things to get done for LINQPad 6 anyway, but leveraging .csx and that ecosystem would eventually be great to see included in LINQPad.

JoeAlbahari

Check out this: https://www.linqpad.net/LinqReference.aspx

alirezanet

+1 on supporting csx files in Linqpad

JoeAlbahari

You can open and run .csx files right now in LINQPad, although not all features are supported. Are you running into an unsupported feature?

ProTip

Hi Joe, I'm using Octopus Deploy's new-ish dotnet-script support. It has the ability to load nuget packages, however I'm seeing the following error:

CS7011 #r is only allowed in scripts

cmiles

Another +1 for basic csx support.

When I open a csx file in LinqPad it doesn't seem to understand/convert the #r style package references and errors with CS7011 #r is only allowed in scripts (of course please let me know if I'm missing an option in LinqPad that supports this!).

I am not a hardcore dotnet-script/csx user so I absolutely don't know everything supported by csx, all the potential complications and various expectations different users might have - but using LinqPad to seamlessly develop csx files that I can then run on any machine/OS regardless of whether LinqPad is installed would be great!

But for me the there would be huge value in Linqpad handling #r package references on opening a csx file, and offering 'save as' for 'C# Statement(s)' into csx (writing package references in #r style and including using statements).

I have voted and commented on UserVoice since this might fairly be more of a feature request rather than a discussion at this point...