Command Line Interface
Make it possible to execute LINQPad and script via a command line script.
linqpad.exe "c:\script.linq" /execute
A beta is now available: www.linqpad.net/beta.aspx. Please let me know your thoughts here: http://forum.linqpad.net/discussion/195/feedback-needed-command-line-interface#latest
Jonathan Stanton commented
This would be a _huge_ benefit, ideally the script.linq would run using the last saved connection properties.
I think the real use would be to able to run linqpad queries from powershell and getting results in a strongly type manner
@Joe - thanks!
I think it's worth noting that there are (at least) 2 different use cases here AFAICT.
For my personal situation, I'm hoping to stick with the 'install for everyone' options where LINQPad gets installed under ProgramFiles(x86) for everyone to use. In that scenario, I'd love to be able to both 'run this script, dump results' from the cmdline (original posting) as well as have a 'supported' automation interface for modifying settings, especially for the scenario of a new machine which just got LINQPad installed, and I just want to have a script that points it at the particular places my scripts will reside (typically based on where I clone my git repos to on the machine), but still want to just use the central 'global' install of LINQPad if possible instead of making my own copy of it.
Admittedly, with your description of what it looks for to override the defaults, just checking in LINQPad into my git repo(s) is looking pretty attractive. :)
Thanks again, Joe!! :)
AdminJoe Albahari (Admin, LINQPad) commented
Alan and James - this has been possible since version 4.43 (see Help | What's new). Copy LINQPad.exe and LINQPad.exe.config into another folder, and inside that folder, create subdirectories called queries, drivers, plugins & snippets. If (any of) these subdirectories are present, LINQPad will use them instead of the normal folder location.
You can even include a different set of connections. If the ConnectionsV2.xml that resides in %appdata%\linqpad\ is also present in the LINQPad folder, it will take precedence.
@Alan Hemmings - completely agreed. I'm really hoping that linqpad adopts what git has - a 'config' command that allows setting these the same way that the rest of linqpad writes (and reads) them.
linqpad.exe config CustomSnippetsFolder c:\foo\linqpad
linqpad.exe config QueryLocations c:\foo\linqpad\queries
linqpad.exe config SnippetLocations c:\foo\linqpad\my-snippets
linqpad.exe config PluginLocations c:\foo\linqpad\lib
In the mean time, as part of setting up my environment on a new machine, after I've used chocolatey to install LINQPad, I then write the AppData files as a way of setting these folders.
Admittedly, this is fragile since these files aren't part of the 'public surface area' of LINQPad (at least, I would imagine), but it's worked well enough, at least with recent 4.x LINQPad versions :)
$linqpadScriptDirectory = "$localDevMiscLocation\LINQPad"
$linqpadAppDataDirectory = "$env:APPDATA\LINQPad"
$linqpadXmlSettings = @"
<?xml version="1.0" encoding="utf-8"?>
Alan Hemmings commented
In order for linqpad to be usable as a deployment tool, in addition to command line interface, we'd need to be able to have seperate linqpad settings for projects. For example, when I'm working on a client project I have to "set folder" so that linqpad scripts that I write get checked into source control, then when I want to work on my own personal projects, I have to "set folder" again, so that I don't accidentally check in my personal linqpad scripts into my clients project. The same goes for my extensions, and plugins, which should be able to be project (or solution) specific.
@hoganlong - IMHO, the McIntyre321 isn't a viable alternative simply because it just compiles and runs the code - in particular, it doesn't create the data context and make that available AFAICT, so it's only useful for scripts that don't do database-related (or do so "manually", without the linqpad-provided datacontext)
Matthew Reily commented
Thanks to McIntyre321 this is available:
just a couple of alternatives (at least until LINQPad supports this) for others that run across this suggestion:
1) Roslyn comes with support for running C# (and I think VB) as scripts (csx files in the C# case)
2) PowerShell can compile/run C# code (and others, of course)
NOTE: if the big 'win' you see from using LINQPad is having it generate the datacontext for the database, you should be able to use SqlMetal.exe or the like to automate that. For instance, as PowerShell script that does so, loads the assembly, then creates and uses the data context should work fine (but I haven't actually tried this).
Mark Johnson commented
Yeah, executing LINQPad scripts via the command line would be useful.
Alan, if you've .NET framework, you can use a bat file and use vbc to compile a code and run the code.
I would like to have linqpad accepting parameters, so I can automates some tasks and schedule in task scheduler. virus writers have tons of other ways to send you a virus
Alan Hemmings commented
I guess this might expose linqpad to being used a vector for virus writers, and would linqpad have to go down the road of signing scripts etc? I want to use linqpad as a replacement for powershell and for assisting with deployments and server configuration.