I suggest you ...

Command Line Interface

Make it possible to execute LINQPad and script via a command line script.

linqpad.exe "c:\script.linq" /execute

529 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    terry.aney shared this idea  ·   ·  Admin →


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      • Rob commented  · 

        Or just open/save .csx files so linqpads fantastic editor could be used alongside scriptcs to run the actual scripts..

        Connection info saved as variables
        References saved using scriptcs #r to reference.

      • Anonymous commented  · 

        This would be a _huge_ benefit, ideally the script.linq would run using the last saved connection properties.


      • AlexK commented  · 

        I think the real use would be to able to run linqpad queries from powershell and getting results in a strongly type manner

      • james.manning commented  · 

        @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.

      • james.manning commented  · 

        @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 :)



        cinst linqpad4
        $linqpadScriptDirectory = "$localDevMiscLocation\LINQPad"
        $linqpadAppDataDirectory = "$env:APPDATA\LINQPad"
        mkdir $linqpadAppDataDirectory

        $linqpadXmlSettings = @"
        <?xml version="1.0" encoding="utf-8"?>
        <UserOptions xmlns="http://schemas.datacontract.org/2004/07/LINQPad">

        [io.file]::writealltext("$linqpadAppDataDirectory\QueryLocations.txt", $linqpadScriptDirectory)
        [io.file]::writealltext("$linqpadAppDataDirectory\SnippetLocations.txt", $linqpadScriptDirectory)
        [io.file]::writealltext("$linqpadAppDataDirectory\querypath.txt", $linqpadScriptDirectory)
        [io.file]::writealltext("$linqpadAppDataDirectory\PluginLocations.txt", "$linqpadScriptDirectory\lib")
        [io.file]::writealltext("$linqpadAppDataDirectory\RoamingUserOptions.xml", $linqpadXmlSettings)


      • 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.

      • james.manning commented  · 

        @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)

      • james.manning commented  · 

        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.

      • andremoraes commented  · 

        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.

      Feedback and Knowledge Base