Any interest to support C# script ".csx" file extension?
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?
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?
Comments
Allowing #include, though, will play havoc with tooling, exception reporting & debugging.
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.
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.
+1 on supporting csx files in Linqpad
You can open and run .csx files right now in LINQPad, although not all features are supported. Are you running into an unsupported feature?
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
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...