DLLs not unloaded when using in edit mode.

[Sibz]

I have play mode working fine, but now looking at some editor scripts, and it appears I cannot release the lock on the files without restarting unity.

Is there any tricks to get DLL unloading working in Edit Mode?

I have checked Enable in Edit Mode, set to lazy, and clicked Unload yet the file is still locked and cannot be replaced/deleted.

[Sibz]

Update, I have it working by un-ticking 'Only in editor'. So there's some bug in relation to this setting.

[mcpiroman]

Untill I look at it, maybe @rogerbarton will have something so say? He has made this feature, as well as some changes to the settings IIRC.

[rogerbarton]

Hmm, based on the usages of 'Only in editor', it should not have an effect like this.

• Is there a load error on any mocked dll?
• Did you enter and exit play mode at least once before enabling in edit mode? (Is this reproducible now?)
• Could you also post a screenshot of the Dll Manipulator Script inspector.

When using this myself I used the keyboard shortcuts most of the time. So there could be a problem with the inspector GUI. Try using Alt+D to unload and Shift+Alt+D to load the dlls (or see the Edit>Shortcuts...>Tools>Load All Dlls etc).

[Sibz]

No errors on any mocked DLL. I never entered play mode, just enabled edit mode. Restarting unity with edit mode enabled produced the same issue once the DLL had been called. (Provided Only in Editor is ticked). Screen shot of working config:

Ok so I had reproduced this previously before logging the issue, and assisted a friend who was having the same issue. Unticking the Only In Editor resolved it for us both. However I have re-ticked and tried to reproduce but it now works as intended.

My previous steps to reproduce was to re-enable Only In Editor, restart unity, call the dll in edit mode. Unload. Then I attempted to delete the DLL which advised Unity had the file locked.

[rogerbarton]

Thanks for the extra info. I tried to repeat your steps in my project, but didn't find the problem.

• Did the 'Mocked DLLs' list say that the dll was LOADED when you tried to delete the dll?
• Did you use the 'Unload, Apply Changes Now & Reinitialize' button at any point?

I'm still not sure why you experienced this, but its good that its working now for you.

[Sibz]

• Mocked DLLs said it was UNLOADED when I tried to delete.
• Yes I probably did that at some point. (I tried swapping Preload/Lazy while trying to get it to work properly).

I glad it's working as intended too, but it wasn't, not just for me, a friend too. I'm mystified because I was able to recreate the problem when I was trying to get it working for my friend, but I can't seem to now.

I'll definitely post again if we run into it again.

[rogerbarton]

Mocked DLLs said it was UNLOADED when I tried to delete.

This sounds like a minor backend bug in DllManipulator.cs when unloading a dll, than a problem with the gui. By changing 'only in editor' the script was somehow (correctly) reinitialized.

I would advise closing this issue, it can be reopened if the issue reappears?

[mcpiroman]

Mocked DLLs said it was UNLOADED when I tried to delete.

This sounds like a minor backend bug in DllManipulator.cs when unloading a dll, than a problem with the gui. By changing 'only in editor' the script was somehow (correctly) reinitialized.

@rogerbarton, couldn't that by any chance be a stale UI, leading to it saying UNLOADED while being in whatever other state? I remember we had issues with refreshing GUI properly.

Otherwise, this in fact doesn't feel like an issue with UI, and particularly not with Only in Editor. I reckon (un)ticking any other option would do the same, which, on the other hand, also seems strange, as the most it should cause is triggering a rather innocent EditorUtility.SetDirty(target).

Anyway, thanks for handling this for me @rogerbarton. I will follow your suggestion and close the issue for now, until I'm given some more stable repro feedback.

[rogerbarton]

The UI could have been stale, this is usually only the case when you change the state without using the UI, e.g. shortcut or another ui window. Although I think these cases have been covered. If the UI is stale, simply hovering over it would repaint it. imo its unlikely that it was a stale UI. Also note that the gui is repainted when a dll is loaded.

Otherwise, this in fact doesn't feel like an issue with UI, and particularly not with Only in Editor. I reckon (un)ticking any other option would do the same, which, on the other hand, also seems strange, as the most it should cause is triggering a rather innocent EditorUtility.SetDirty(target).

Agree.