Dependencies
Dependencies copied to clipboard
lucasg
missing dependencies are not marked upwards according to the dependency hierarchy
I search for one bug regarding dll dependencies where I found some bug in the dependencies tool. In the case of missing dll deeper in the tree, it is not shown at the top level.
Here is an example. You see here that all dependencies of kernel32.dll are found.
When you open the tree of the dll, you see that some dlls are not found.
Came here to post the exact same issue; I'm not sure if this new behaviour because IIRC I've used Dependencies before to track down missing dependencies, but yesterday I had the same problem: only after manually walking the tree the missing dll was shown. For me it was 4 levels down so that takes a while. These aren't delay-loaded dlls if that matters. It almost defeats the purpose of the tool (or at least, the main reason I use it for).
However, the README mentions how to fix this: under the Options->Properties menu there's a Tree build behaviour option where you can select to build the complete tree recursively. In other words: this issue is actually fixed already, just need to RTFM :]
Unfortunately that does not fix the described issue. Each parent will be marked as "OK" anyways.
as you see here it does not work with the property "recursive" tree build behaviour.
so much zu your RTFM
The only thing which doesn't work is parents being marked when a child dependency is missing; note if that would be done pretty much anything you load would be marked "NOK" since the api-ms-win-core-xxx dlls are always missing but that doesn't matter at runtime - that's about as helpful as the current situation, i.e. not at all. However enabling recursive search does immediately populate the lower pane and as such does allow you to quickly see what is missing without having to go through everything manually first.
There can be improvements though, like making RecursiveOnlyOnDirectImports the default and automatically expanding tree items with missing dependencies. Especially the latter would be the most useful, way more so than marking parents if children have a problem since that still doesn't solve the problem of manually having to travers the tree to hunt for missing items.
@photoniker : I've pushed a commit which propagate child module errors to the parent in the tree view : https://github.com/lucasg/Dependencies/commit/ce00db193612675b2edebe654431ad119e5fa971
(red means "module has errors", orange means "module was loaded successfully, but has child errors", the tooltip was also updated)
There is still a big gotcha : the tree view is constructed lazily in order to speed up construction, which means some dependency issue 3-4 level down may not be visible since the erroneous module is not yet parsed.
There is also the issue of delay-load dependencies which may or may not be a problem based on which imports are called and when...
This issue is vastly improved for me in version 1.11, versus 1.10. In 1.10 TBH none of the recursion options seemed to change the behavior. In 1.11, "RecursiveOnlyOnDirectImports" does not bubble my missing dependencies up in the hierarchy view, but it does populate them in the bottom pane, where sorting by the unlabeled leftmost column reveals the issues quickly. Like @stinos described two messages up from here.
Except there's a bug where each time the top binary is clicked, its direct dependencies are appended to the lower pane list again even though they are there already. E.g. I have an exe which depends only on kernel32, vcruntime140 and ucrtbase. If I click on kernel32 in the tree, then on the exe, those 3 dlls are added to the lower pane. When repeated, it happens again.