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.
Well you could use https://www.gnu.org/software/dotgnu/ to compile
Jude Boka commented
why not installing Rosalyn and use "csc" to compile the file
@raboof thanks for the link!
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.
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?
Also if the output exe could be IL merged with in NuGet packages referenced
Here is my take to compile a LinqPad query as Dll or Exe by generating a msbuild project file: https://github.com/wangzq/lpmake
It supports nuget packages by leveraging project.json support in nuget 3 and latest msbuild.
Eric Wu commented
@JohnStevens, I am. Mind sharing? :)
John Stevens commented
I have a way to generate an assembly from a LINQPad script with a LINQPad script if anyone is interested
Michael Surikov commented
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.
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
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
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.
Why not use powershell ? It has access to the .Net classes and assemblies
Michael Maguigan commented
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.
Andrew McClenaghan commented
Would love the ability to embed this into a web project. Easy way to give our end users custom reusable scripts.
Daniel Rubin commented
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.
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.
Keith Hall commented
why not just use lprun? http://www.linqpad.net/lprun.aspx
Franklin Ross commented
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.