Releasing DLL's locked in Interactive Session - maybe related to issue 411?

Mar 20, 2012 at 9:22 PM

Thanks again for the awesome work you guys do.

I did want to let you know that I am not having any luck with the issue reported as fixed in 1.1:

I think I am mainly confused about what it takes to "unload" an assembly from an interactive session. I have tried resetting it with the reset button in the interactive window, but it seems to keep the locks on the .DLL's that I am using, which does happen to be in the same solution. 

It is very possible I could be "doing it wrong." I have added references to my two other projects in my solution, but I cannot add them to my IronPython script unless I use clr.AddReferenceToFileAndPath. The moment I do that, it keeps a lock on that DLL file until I restart Visual Studio.

I've tried adding search paths as well, but I guess the interactive session really has nothing to do with the project's References or Search Path. Could you give me any guidance on how to just simply unload the DLL from an interactive session so I can rebuild my solution without restarting Visual Studio each time?

Take care,

Russ Frizzell

Mar 20, 2012 at 9:27 PM

Resetting the interactive window should cause the assembly to be unloaded if it's the interactive window which is keeping it open. 

Are you by any chance starting PTVS under the VS debugger when this repros (e.g. doing a custom build, and rather than installing running from inside of VS?)  That will actually cause the outer VS to keep the files locked when they get loaded into the inner VS.  If you're debugging in the inner VS it might be possible that it is locking the files as well, but it should release them once you stop.


Mar 20, 2012 at 9:41 PM

Well, bear with me here...

My build is from within VS for my non-(Iron)Python projects...nothing really custom unless you count the new NuGet auto-restore package feature.

I will agree that I believe VS is the one locking the files...I used Process Explorer to see who had the locks on them, and it did report devenv.exe had the lock.

The Launch mode in the Project properties for the Python project is set to use the IronPython (.NET) launcher.

Let me know if I can tell you any more of my settings.

Thanks for the quick response...


Mar 20, 2012 at 10:34 PM

Ok, it does definitely look like using AddReferenceToFileAndPath will still lock the assembly on disk :( I repro'd this by creating a new IronPython project, adding a C# project, and then doing the AddReferenceToFileAndPath with the full path, and yep, it's locked.

I doubt that's what you really want long term though...  for starters that path is going to be different on your machine then if you move the script somewhere.  I think in the end you're going to want to package your .py files + your .dll as a whole (correct me if I'm wrong).  So what I'd recommend doing is going into the C# project properties and changing the output path to be the Python project dir.  You already have the references form the Python project to the C# project so that is good.  Finally clr.AddReferenceByName('ProjectNameWithoutExtension').

For development time we'll pick up the reference via the references tab (rather than loading the assembly directly), and at runtime we'll pick up the assembly in the current directory.  Hopefully now your development time and real run-time scenarios are the same, so everything should always work the same.

I'll open a bug so we can fix the AddReferenceToFileAndPath issue.

Mar 20, 2012 at 10:34 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.