Dump depth and Locked referenced dlls in v4.41.02
There are two annoying behaviours after the auto update to the newest version of linqpad.
1. We're connecting using entity framework. In the current build, the Dump() command frequently stalls because it's traversing all the linked relationships between the tables for a simple query e.g Table1.Take(1).Dump();
So to get around it, we have to do Table1.Take(1).Dump(2); For the query to return.
2. Dlls in the additional references appear to be locked after a query is run on them. They cannot be overwritten and if deleted will just reappear immediately until linqpad is stopped and restarted.
1. We're connecting using entity framework. In the current build, the Dump() command frequently stalls because it's traversing all the linked relationships between the tables for a simple query e.g Table1.Take(1).Dump();
So to get around it, we have to do Table1.Take(1).Dump(2); For the query to return.
2. Dlls in the additional references appear to be locked after a query is run on them. They cannot be overwritten and if deleted will just reappear immediately until linqpad is stopped and restarted.
Comments
LINQPad should not lock additional references unless they are in the ProgramFiles or Windows directories. Where abouts are the files that you're referencing? Also, make sure you haven't disabled shadow-loading (Edit | Preferences | Advanced).
On the shadow feature, I'm not sure if my logic has been inversed or yours but the property that says
'Do not shadow assembly references' is set to false by default.
With this setting, the dlls that i'm using (not in program files or windows) are locked after running a query.
However, if i turn it to true (which i thought is the inverse logic meaning, lock referenced dlls) then it actually doesn't lock the referenced dlls and allows me to build over the referenced dll and perform queries! so i'm leaving it on true until you tell me so.
I cannot imagine why shadowing doesn't work in your situation. Does it fail with just some assemblies, or all of them? Is it possible that one of your assemblies is explicitly calling Assembly.LoadFrom with the original path of the assembly that's being locked?
Can you try setting that option back to the default (False), restart LINQPad and run this:
// First do something that calls upon one of your referenced DLLs:
//...
// Now list the assemblies that are loaded in the current AppDomain:
AppDomain.CurrentDomain.GetAssemblies().Dump(1);
You should see all your referenced DLLs in memory. Can you tell me what appears in the CodeBase/Location of the ones that you're referencing? Also let me know whether they appear just once or multiple times.
Ran a query that uses both my referenced dlls and then called GetAssemblies().
It returns to me one instance of both dlls.
The codebase looks like this:
file:///O:/LINQPad Queries/lib/Ref1.dll
file:///O:/LINQPad Queries/lib/Ref2.dll
The location looks like this:
O:\LINQPad Queries\lib\Ref1.dll
O:\LINQPad Queries\lib\Ref2.dll
These are the exact locations that I copy the dlls to.
Then trying to compile on vs gets me the error that I cannot copy over the dlls (because they are locked).
I have a post-build xcopy of the assembly to a shared folder where everyone can reference the dlls (i've also made sure it wasn't any other linqpads in the network holding on to the dlls).
When I set 'Do not shadow' to True, restart, run query
The observed codebase and locations are identical, however I am able to build and copy over the dlls without errors BUT (new discovery) no one else is.
download.linqpad.net/special/LINQPad4.zip
and then after running a query, tell me what's written to %localappdata%\linqpad\logs\log.txt?
I replied to your email with the relevant log details. Did you want me to post it here too?