lprun cleanup.
I invoke LPRun.exe from inside an eternal loop in a query that is executed inside LINQPad.exe
After a few days, it runs out of disk space.
The problem is that AppData\Local\Temp\LINQPad quickly grows big.
I can do a cleanup as part of the MasterQuery by getting the folder of executing assembly and Directory.Delete() all of its siblings. However, this is ugly and may disturb other stuff that I'm doing in LINQPad.exe in other tabs than the MasterQuery.
Is there another way? Does LINQPad.exe delete output binaries when a query has completed (and closed so that the result window no longer references objects inside the binaries)? And, if so, can LPRun.exe also do this?
After a few days, it runs out of disk space.
The problem is that AppData\Local\Temp\LINQPad quickly grows big.
I can do a cleanup as part of the MasterQuery by getting the folder of executing assembly and Directory.Delete() all of its siblings. However, this is ugly and may disturb other stuff that I'm doing in LINQPad.exe in other tabs than the MasterQuery.
Is there another way? Does LINQPad.exe delete output binaries when a query has completed (and closed so that the result window no longer references objects inside the binaries)? And, if so, can LPRun.exe also do this?
Comments
In the meantime, you can work around the problem (and also improve the efficiency of what you're doing) by using Util.Run. This lets you run one query from within another.
These are memory intensive queries and with occasional 32 bit library dependency, so my reasoning was that Util.Cmd was a better fit to lessen the chance of an OutOfMemoryException by not sharing memory consumption with the outer query.
Using Util.Cmd also allows me to occasionally call into the 64 bit version of LPRun.
I would like nothing more than to hear that my concerns were misguided.
Skipping the recycle bin it will take over 5 hours to delete all of these files
Hope a fix is in soon!!
Let me know how it works for you.