This is caused by the BinaryCache component,
that keeps a list of filenames, as well as a list of (partial) file hashes.

Some possible solutions:

1. Flush the FilepathDatabase when reloading files,
2. Check 'Last Modified' of the file against the cache
3. Drop the FilepathDatabase and uses hashes only

Yep, the BinaryCache component is pretty iffy, and was written before explicit refresh was a feature. For performance reasons, I try to reload from disk only when needed, but there are a lot of edge cases I missed.

I'll try to push a fix in the following week.

This is still an issue, has spent some time closing a dll tab and dragging a dll back - with no changes I thought I was doing something wrong with my code and compiler config. I started using this lib just yesterday mainly because of this feature vs the legacy dependencywalker.exe, which used to hold a lock on file until the app is closed. So this is big for usability.

+1 for this, just lost an hour trying to figure out why our build was linking against Debug CRT in Release config, just to realize this was only a problem of display and the build was perfectly fine all along... 😞

Note: As of 1.10 this seems not to be a problem with import names per se, but still persists to be an issue with delay loading attributes. Cases like this still result in incorrect enumeration:

1. Have foo.exe file link against bar.dll
2. Open foo.exe in DependenciesGui
3. Recompile foo.exe to delay load bar.dll instead
4. In DependenciesGui, Hit Refresh - bar.dll still shows as not delay linked
5. In DependenciesGui, close and reopen foo.exe - bar.dll still shows as not delay linked
6. Close and reopen DependenciesGuiand reopen foo.exe - bar.dll does now show as delay linked

For what it's worth, it seems like the BinaryCache component is doing more harm than good... Is it really beneficial to keep it alive throughout the entire session rather than invalidating the cache completely on Refresh and closing the file?

I had the same issue but pressing F5 worked for me.

I'm running into the same problem, both with Refresh and with closing and reopening the file (only restarting DependenciesGui.exe helps).

I don't know how the BinaryCache currently works (or what it does exactly), but does it already check if the timestamp of the cached DLL has changed since its data has been cached?
I'm not sure if that fixes the issue in all cases, but it should probably help for the common "I recompiled the DLL but Dependencies didn't show the changes" issues.

Alternatively, is there a way to disable this BinaryCache feature?

I have same issue.

Still an issue I lose an hour of trying to fix my DLL exports with before realizing it was this Dependencies tool being broken...