Is LINQPad worth it?
I remember a while ago a few coworkers really championing LINQPad. Is it still worth its cost today?
It seems like its killer functionality is that it can connect to a database, generate a LINQ to SQL context for easy querying, and dump the results in nested grids. Is this correct? If my database doesn't have foreign key constraints for its foreign keys, this is a lot less useful, right?
Does anyone here use it? What do you use it for? Would you recommend it?
Does anyone have a license and no longer use it? Why did you stop using it?
Comments
I have been using it for at least 12 years and it has definitely been money well spent and definitely recommended.
I have currently over 1900 linq files that I have decided to keep on my machine and probably as many more one-off queries that I have not kept and others than I have written when connected to remote machines.
The vast majority of these are using the automatic Linq to Sql connection, but some are using a pre-built Linq2sql or EntityFramework data context models and others connecting to SqLite databases and even csv and json files.
There are also some queries that don't have any data connection at all. At the moment I am working on some code which connects to a webservice using an api and I am prototyping this in LinqPad where it is a lot easier to dump out the json results.
I have another script which I use at home which connects to a spreadsheet in google drive and downloads some information and syncs this to a Trello board all using their apis. It could all be doing in Visual Studio, but is ten times easier in LinqPad and because this is just for myself, it will probably stay as a LinqPad script.
Also the formatting you get from Dump / CreateXhtmlWriter is probably worth the money on its own. Some much so, that I have referenced LinqPad.exe in some of my projects in order to use it.
If your database structure does not have foreign key constraints for its foreign keys, then writing queries will be a lot harder. I have had to extract information from an un-documented sql database with no FK's and it wasn't pleasant. However, this is a feature of the model not the database at run-time, so if you have a pre-defined model that does specify the relationships between the tables then this disadvantage dis-appears.
If it helps, 80% of the queries that I see use no database at all. LINQPad is used mainly for scripting and automation, exploring APIs and playing with NuGet packages, testing ideas, and writing code that's later pasted into Visual Studio.
I'd say it's absolutely worth it for trying out new language features with IDE support and building simple tools for processing and analyzing data.
Database access to me is secondary nowadays but it's still a great tool for those who are not well versed to working with them. All the hard stuff is taken care of for you; connecting to the database and provide interfaces for you to interact with it. You might need to do some work if you don't have the relations defined to shape the data the way that you want, but that's not going to stop you from querying it. Since we're just running code here, you could always create the functions ("views") that you want to recreate these relationships.
Majority of the time the scripts I write are for my use but occasionally I script out something that might be useful for other teammates. I could then share this script with them and they'll be able to benefit from it. They just run it and don't need to install anything else other than LINQPad. There's a lot of value in taking the contents of a large XML file for example that contains data that needs to be groked by someone in an easy to read format. You can write a script to present the data in a nice format, possibly even perform calculations on the data, then generate a report on the data.