I suggest you ...

Give option to generate EXE

It would be nice to be able to fine tune my query then click "make EXE". An executable would be produced that just ran the query and showed the Dump results as if I had run it directly in LINQPad. A more advanced option would be to allow some simple parameters to be passed and used in the query. This way I could write some simple reporting queries and then give them to someone else or add shortcuts to easily run them again myself.

1,437 votes
Sign in
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
Scott Isaacs shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Password icon
Signed in as (Sign out)
  • raboof commented  ·   ·  Flag as inappropriate

    So while waiting for this to become available as part of LINQPad proper, I've scratched my itch as the project LinqPadless:


    For those of us using LINQPad as a mere lightweight IDE, it enables turning LINQPad scripts/queries into stand-alone C# scripts (csx) or executables for automation and distribution to others. If you rely on all the run-time bells & whistles of LINQPad then this is not for you. See documentation limitations.

    I'm sharing this in the hope that there may be interest in collaborating on the project.

  • Ash commented  ·   ·  Flag as inappropriate

    If Linqpad could build assemblies, along with integrated debugger etc, I wouldn't need to touch Visual Studio for many applications. Hmmm, I wonder why such an obvious feature hasn't been added?

  • John Stevens commented  ·   ·  Flag as inappropriate

    I have a way to generate an assembly from a LINQPad script with a LINQPad script if anyone is interested

  • Michael Surikov commented  ·   ·  Flag as inappropriate

    lprun.exe is not an option when you need to start multiple instances of the same or different LINQPad scripts at about same time because of lprun.exe first cleans up "old" files in its temporary folder like %TMP%\LINQPad and finally it deletes (!??) this folder at all. So, some instances can not find their compiled dll's as they were deleted by another instance of lprun.exe. This is why I vote for an ability to generate exe files for my LINQPad scripts to do not compile on the fly.

  • Matt commented  ·   ·  Flag as inappropriate

    Why not add support for the C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe commandline compiler? Should not be too difficult to include a converter which generates *.cs files ... if some restrictions apply, like ommitting the .Dump() and use the Console.WriteLine() instead, it seems to be achievable. Something like a "Generate console app from LinqPad project". Like Martin already mentioned ... but the issue is that a LinqPad file handles the references differently, so something like an "export to console app" would be great.

  • Martin Kirk commented  ·   ·  Flag as inappropriate

    soooooo ... why don't you simply copy the code to Visual Studio to a Windows Commandline solution ?

    the output/dump would be the only issue - but easily solvable.

  • Sergii Sakharov commented  ·   ·  Flag as inappropriate

    One more use case - IL generation/weaving testing. Used to be quite easy with snippet compiler which had this option.
    lprun is completely irrelevant in this case.

  • Dave commented  ·   ·  Flag as inappropriate

    Why not use powershell ? It has access to the .Net classes and assemblies

  • Michael Maguigan commented  ·   ·  Flag as inappropriate

    lprun isn't really an option if my intention is to create an executable to hand off to another team for an ad-hoc script to be run on another departments equipment.

  • Daniel Rubin commented  ·   ·  Flag as inappropriate

    Lprun only handles some of the usecases which this suggestion would enable. It doesn't allow (as Franklin Ross suggested) creating a *distributable* exe file.

    https://linqpad.uservoice.com/forums/18302-linqpad-feature-suggestions/suggestions/1520279-ability-to-save-a-compiled-linqpad-script-to-an-ex was suggested to be a duplicate of this, but if lprun is considered to be "sufficient" to close this, then that feature will still be unaddressed.

  • james.manning commented  ·   ·  Flag as inappropriate

    Agreed with Keith - with recent versions, using lprun.exe seems like it's sufficient to cover this use case, and we can/should close this.

  • Franklin Ross commented  ·   ·  Flag as inappropriate

    This would be great! I've been thinking about this for a while because I pretty frequently write little LINQPad scripts for pulling some data out of a few files or a DB for a non-tech. Being able to create an exe that I can give them to run themselves would be great.

    I'm currently seeing how I go writing a mini UI library for easily prompting the user for some inputs in a LINQPady kind of way, like 2 file open dialogs for instance (or whatever). Ideally the same exe would be able to parse command line arguments for the inputs too. We'll see how I go (I just started), but this suggestion would complete that whole thought into a quick tool creator.

← Previous 1

Feedback and Knowledge Base