Dump depth and Locked referenced dlls in v4.41.02

edited April 2012
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.


  • Options
    The first point has been fixed in 4.42. You can download it now, or wait a day and it will be rolled out automatically.

    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).
  • Options
    Timely fix, thanks joe.

    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.
  • Options
    The logic is not inversed. What's happening is that when you disable shadow-loading, LINQPad locks your assemblies, but then it starts a timer which monitors which application is active. When you switch to Visual Studio or Visual Studio Express, LINQPad attempts to unload the domains of queries that have finished running and that reference additional DLLs that you may want to rebuild in VS. This is a workaround rather than an ideal solution, because some things can prevent it from unloading (or cause it to unload when it shouldn't).

    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:

    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.
  • Options
    So setting 'Do not shadow' to False (default) and restarted linqpad.
    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.
  • Options
    Thanks for the info. Can you try again with this build:

    and then after running a query, tell me what's written to %localappdata%\linqpad\logs\log.txt?
  • Options
    Hey Joe,

    I replied to your email with the relevant log details. Did you want me to post it here too?
  • Options
    I've got it. Will contact you by email.
Sign In or Register to comment.