Refresh or reopening a dll does not refresh the display

[netx123]

I have found that when using DependenciesGui.exe, the Refresh menu option and also reopening a dll does not refresh the display.

1. Drag a dll onto the window
2. Observe the dependencies
3. Make a change to the dll so there is a difference in dependencies (such as re-compile it with a different toolset)
4. Click the View->Refresh option

Expected result: I expected to see the different dependencies no showing Actual result: The previous dependencies still show

Further more closing the tab for that dll (not closing the app) Then dragging the dll back to the DependenciesGui.exe window, also still shows the old dependencies.

However, closing the DependenciesGui.exe application completely, and then opening the dll does then show the new expected dependencies.

[learn-more]

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

[lucasg]

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.

[buybackoff]

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.

[djee-ms]

+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... 😞

[CookiePLMonster]

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?

[hsonne]

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

[DanielGibson]

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?

[iamyaoting]

I have same issue.

[RayKoopa]

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