Embedding/Attaching/Linking LINQPad inside another application like VBA for desktop app automation?
Is it possible to embed LINQPad as a scripting solution similar to VBA inside Excel?
In other words load LINQPad (In-Process) in such a way that LINQPad code can script another application via its API. I tested several solutions but each either causes the debugger not to work or I have to load my app inside LINQPad's process which works but requires my code to be attached to a query/process (.linq file). Also any changes to the code will require me the rerun the query killing my app's active process or create a new instance with the new code changes while continuing to run the older instances.
COM works well but COM support in dotnet core and 5+ is not complete and many older desktop apps require raw COM for automation and some without Interop assemblies. This limits me to LINQPad 5 (.net 4.8) for COM based solutions.
I have written plugins and extensions that integrates LINQPad with 3rd party desktop apps and my own tools but I want an experience closer to VBA in Excel with all the features especially debugging. My next and maybe final idea is to build a code editor I can embed anywhere and integrate LINQPad as a library compiling queries with my own toolchain. This maybe the only way.
Thanks
Comments
You could use VBA's
Shellcommand along with LINQPad'slprun. Ex:Shell("lprun foo.linq", vbHide)LINQPad - lprun
VBA - Shell function
I use VBA/VBScript for COM based solutions and LPRun for commandline tools already. What I want to do is use LINQPad as a replacement for VBA in Excel for example. I want to use LINQPad a scripting IDE for software that have API's.
@JoeAlbahari do you have any recommendations or ideas? This may be outside of the core use case, but I think many of LINQPad features play well in environments where VBA, VSTO and VSTA once dominated.
I have a solution. I use Mathematica to connect LINQPad/LPRun with other programs including .net 4.8, .net 5+ and COM processes.
Thanks for the update. Can you describe how you accomplished it?
Building for Architecture, Engineering and Construction 2D and 3D workflows e.g., Autodesk apps, MicroStation, SolidWorks, Rhino, Alibre Design, Unity 3D, SolidEdge, DraftSight and many others. Most of these apps only have COM API's and are only programmable with .NET framework since these are really old applications written decades ago (and no one has updated API's to core or later and likely won't). Many of them are moving to the Cloud or web based tech.
Software with COM API's can be automated in LINQPAD without issues, but this is LINQPad 5 only.
The way COM is implemented varies from Software to Software and so far none I've tested work completely with .NET 5 or 6. I have VS solutions for sharing new (.NET 5+ ) code with COM (.NET 4.8 ) code when starting new projects but this is case by case.
I write wrappers for dotnet 4.8, 5.0+ and COM for use with 3rd party API's basically, class libraries, console apps and LINQPad plugins that bridge any gaps needed.
Load software in-process within LINQPad to allow for a better run / debug cycle when possible. This only work if the 3rd party software process can be loaded inside LINQPad. This makes the code debuggable from LINQPad for a VBA like experience.
Create plugins for each host app to compile and run LINQPad files as macros. For example, I created a Rhino 3D plugin that compiles and runs .linq files. This makes it possible to development in LINQPad (IDE) or VS Code not Visual Studio providing a much faster dev/test experience. LINQPad debugging is not possible from within the host app because LINQPad runs in its own process/app domain out-of-proc. There are ways to attach debuggers and reflect assemblies for debugging but those defeat my purpose. This approach is great for building new features and functionality for a running app like writing and running ad Hoc macros.
Using a combination of CS-Script, Rosyln scripting and .NET Interactive to fill-in holes where LPRun cannot like REPLing. .NET Interactive is .NET >=5. Running LPRun scripts from inside .NET interactive Notebooks is a way to move some code forward without rewriting it while making use of new tech.
Using Wolfram Notebooks to link all the various API's and processes together in one place.
Much more to discus this is just an overview.
I'm exploring .NET Interactive more because I recently noticed after LINQPad scripts are made I rarely change them so having the ability to use them inside a Notebook or REPL is awesome. Simply calling .NET scripts in a pipeline compiling on the fly is much faster than working directly with dll's. This allow you to embedded .NET scripting in an App and use LINQPad as the IDE.