A long-time satisfied user of LINQPad. It is one of my must haves. I usually upgrade to the latest one when I hit some framework feature or a piece of snippet which requires it. It started as a very reasonably priced for the paid edition and there was only one paid edition for a long time. Nowadays, it is a bit pricier and has several editions (a suggestion would be to merge Pro and Developer editions).
I use LINQPad to manage my collection of snippets to do some ad hoc tasks on my machine. I also use it for testing out new code and learning about new features. It would be great when it becomes cross-platform, but last I heard Jo Albahari mentioned that the investment required was quite big and not worth it (at that time).
On the side note, I had a chance to see Jo Albahari's presentation few years ago in Sydney and I think he is unsung hero of .NET world (along with Ayende)!
Regarding a cross-platform version of LINQPad, I'm actively working towards supporting MacOS. I can't give a timeframe right now, but it might be sooner than later if XPF turns out to be a viable option.
A true essential tool. One of the few pieces of software for which I own a personal license.
One of the useful features is that it keeps the executable running even after the script has finished, and will re-execute in the same process.
This has some downsides and quirks (if you're not careful, you can double-initialize things like database connections), but has benefits for debugging.
The newer versions have "built in" support for Benchmark.NET too which is a really nice feature for quickly proving code.
Great piece of software that I basically use for scripting/notebooking. Been writing C# so long it's my lingua franca and this tool lets me do pretty much everything (except actual shell scripting for use on e.g. build servers and deployment pipelines) in C#.
Linqpad is one of the few tools that do what they need to do without much fuzz and in a straightforward manner. Beyond Compare is also in the same category.
I am glad that the UX people haven't gotten around to mess it up yet.
The only reason I would use something like LINQPad is for the syntax tree and semantic analysis support, for compiler extensions. With a name like RoslynPad, seems funny that such a feature would be missing from that "alternative"
I haven't used Linqpad in a long time but one of the most useful features it had was the ability to add connections to your SQL Server databases and then write quick throwaway LINQ/Lambda style syntax queries against it, e.g.
I don't bother making anything run on linux unless it's meant to run as a service. It's just not worth the time and trouble to test it on multiple operating systems, probably with different libraries, just for what is a very vocal minority.
In particular, keyboard shortcuts to toggle visibility on the different sub-windows, and using the Util class to prompt for a password I find to be useful.
The hosting API is completely different. Roslyn handles VB.NET and C# with basically the same API. Adding PowerShell is akin to writing the core part of all that a second time. Not that it can't be done, but most of the time PowerShell itself is already a capable REPL, so I guess there's also less need for it in LINQPad.
I love LINQPad, it reminds me of first learning to program via DrJava in college. Just write and run code, completely free from all the configuration, structure and other concerns related to building and shipping a binary or other deliverable.
I’ve never got used to linqpad over just creating a console app and writing code, it may be because I’ve never been one for keeping a collection of snippets?
One of many useful features of LINQPad is the output visualizer ("Dump"). Granted, there are now NuGet packages (very likely inspired by LINQPad) that can do something similar in a console app but LINQPad is interactive, allows drill-down and can export to formats like Excel. It's such a productivity boost.
The database integration is also great and allows me to write ad-hoc SQL queries using LINQ.
That's exactly the kind of thing I always hated about .net -- how the absence of a REPL forces me to create an executable for even the tiniest things. LINQPad solves this beautifully. Not sure if index ranges are inclusive or exclusive? Open LINQPad, double-click tab bar to open a new tab, type `"0123"[..^2]`, press ALT+X, done. I'd never go through the hassle to create an executable with VS for that, so instead I have to look up the documentation which is much more boring. And what's even better: countless times I was wondering what happens inside the framework and because LINQPad comes with ILSpy (I believe so, maybe you'll have to set it up) you can just F12 a framework method to see its source.
As someone with a strong bias towards interactive, investigative, "library-first" development, LINQPad is an essential part of my C# toolkit, as every other C# REPL and interactive environment I've tried has come up short in one significant way or another.
Essential LINQPad productivity features for me include:
1. Flexible visualization tools with sensible defaults and one-click export.
2. Ability to easily round-trip copy/paste code snippets between LINQPad and external IDE projects with minimal fuss (e.g., no boilerplate required for expressions, statements, or simple functions).
3. Automatic reloading of libraries I'm working on externally in an IDE with minimal IDE rebuild interference.
3. Completion on par with VS.
4. One-click document cloning.
5. NuGet integration, including the ability to search for and update referenced packages.
6. A simple, built-in debugger.
A typical LINQPad workflow for me (excluding tasks like writing documentation and unit tests for brevity):
1. Start with a task of accessing or exporting data from either a set of files in an unknown format or from an application — ideally, but not always, a Web application — without a documented API.
2. Create a library project in Rider or VS and a LINQPad document referencing the library.
3. Investigate the files or application interactively using LINQPad and other tools (hex editors for investigating binary formats, jq/IPython/PowerShell for JSON and XML, browser dev tools for Web apps, accessibility tools when automating Windows desktop apps, etc.).
4. Add data access mechanisms to the library.
5. Repeat steps 3 and 4 as necessary, with more and more work being done in LINQPad via the library on each iteration.
6. Build simple command-line or graphical tools on top of the library to allow non-programmers to access or export data from similar systems in the future without LINQPad. In cases where non-UI logic in these tools becomes non-trivial, I'll typically prototype this logic in LINQPad and extract it into a library, as well.
Finally, as new requirements arise, I can load up existing libraries and LINQPad to analyze and prototype solutions, often leading to initial results delivered to customers in minutes rather than hours.
[+] [-] justgaurav|1 year ago|reply
I use LINQPad to manage my collection of snippets to do some ad hoc tasks on my machine. I also use it for testing out new code and learning about new features. It would be great when it becomes cross-platform, but last I heard Jo Albahari mentioned that the investment required was quite big and not worth it (at that time).
On the side note, I had a chance to see Jo Albahari's presentation few years ago in Sydney and I think he is unsung hero of .NET world (along with Ayende)!
[+] [-] LINQPad|1 year ago|reply
[+] [-] xnorswap|1 year ago|reply
One of the useful features is that it keeps the executable running even after the script has finished, and will re-execute in the same process.
This has some downsides and quirks (if you're not careful, you can double-initialize things like database connections), but has benefits for debugging.
The newer versions have "built in" support for Benchmark.NET too which is a really nice feature for quickly proving code.
[+] [-] rjbwork|1 year ago|reply
[+] [-] gdev_gabe|1 year ago|reply
[+] [-] rqtwteye|1 year ago|reply
I am glad that the UX people haven't gotten around to mess it up yet.
[+] [-] johnnyballgame|1 year ago|reply
[+] [-] smokeydoe|1 year ago|reply
[+] [-] Nuzzerino|1 year ago|reply
[+] [-] vunderba|1 year ago|reply
[+] [-] runevault|1 year ago|reply
[+] [-] jodrellblank|1 year ago|reply
[+] [-] novaleaf|1 year ago|reply
[+] [-] Nuzzerino|1 year ago|reply
https://forum.linqpad.net/discussion/1935/installation-on-ma...
[+] [-] anotherlab|1 year ago|reply
It's not as good as LINQPad, but it runs on the Mac.
[+] [-] qiller|1 year ago|reply
[+] [-] misterflibble|1 year ago|reply
[+] [-] webprofusion|1 year ago|reply
[+] [-] Ntrails|1 year ago|reply
[+] [-] vsuperpower2020|1 year ago|reply
[+] [-] kagevf|1 year ago|reply
In particular, keyboard shortcuts to toggle visibility on the different sub-windows, and using the Util class to prompt for a password I find to be useful.
[+] [-] mnau|1 year ago|reply
I used to purchase premium version (single user) and the upgrade option is $97.50 instead of $125 for new license.
[+] [-] ryncewynd|1 year ago|reply
[+] [-] RexM|1 year ago|reply
[+] [-] BadJo0Jo0|1 year ago|reply
[+] [-] deanebarker|1 year ago|reply
[+] [-] replwoacause|1 year ago|reply
[+] [-] ygra|1 year ago|reply
[+] [-] readergreader|1 year ago|reply
[+] [-] judah|1 year ago|reply
[+] [-] nlawalker|1 year ago|reply
[+] [-] ed_elliott_asc|1 year ago|reply
I’m not against it, I just don’t need it
[+] [-] liversage|1 year ago|reply
The database integration is also great and allows me to write ad-hoc SQL queries using LINQ.
[+] [-] bertylicious|1 year ago|reply
[+] [-] lf-non|1 year ago|reply
[+] [-] jasomill|1 year ago|reply
Essential LINQPad productivity features for me include:
1. Flexible visualization tools with sensible defaults and one-click export.
2. Ability to easily round-trip copy/paste code snippets between LINQPad and external IDE projects with minimal fuss (e.g., no boilerplate required for expressions, statements, or simple functions).
3. Automatic reloading of libraries I'm working on externally in an IDE with minimal IDE rebuild interference.
3. Completion on par with VS.
4. One-click document cloning.
5. NuGet integration, including the ability to search for and update referenced packages.
6. A simple, built-in debugger.
A typical LINQPad workflow for me (excluding tasks like writing documentation and unit tests for brevity):
1. Start with a task of accessing or exporting data from either a set of files in an unknown format or from an application — ideally, but not always, a Web application — without a documented API.
2. Create a library project in Rider or VS and a LINQPad document referencing the library.
3. Investigate the files or application interactively using LINQPad and other tools (hex editors for investigating binary formats, jq/IPython/PowerShell for JSON and XML, browser dev tools for Web apps, accessibility tools when automating Windows desktop apps, etc.).
4. Add data access mechanisms to the library.
5. Repeat steps 3 and 4 as necessary, with more and more work being done in LINQPad via the library on each iteration.
6. Build simple command-line or graphical tools on top of the library to allow non-programmers to access or export data from similar systems in the future without LINQPad. In cases where non-UI logic in these tools becomes non-trivial, I'll typically prototype this logic in LINQPad and extract it into a library, as well.
Finally, as new requirements arise, I can load up existing libraries and LINQPad to analyze and prototype solutions, often leading to initial results delivered to customers in minutes rather than hours.
[+] [-] XajniN|1 year ago|reply
{ "file_patterns": ["*.cs"], "cmd": ["dotnet-script", "$file"] }
[1] https://github.com/dotnet-script/dotnet-script