Which command line tools exist to recursively find all DLL dependencies? I tried dumpbin and Dependency Walker (aka Depends.exe) that come with Visual Studio, but dumpbin only finds the first level of dependencies, and the output of Dependency Walker is not really computer friendly.
相关问题
- How to know full paths to DLL's from .csproj f
- Inheritance impossible in Windows Runtime Componen
- how to get running process information in java?
- Is TWebBrowser dependant on IE version?
- How can I have a python script safely exit itself?
相关文章
- 如何让cmd.exe 执行 UNICODE 文本格式的批处理?
- 怎么把Windows开机按钮通过修改注册表指向我自己的程序
- vs2017wpf项目引用dll的路径不正确的问题
- Warning : HTML 1300 Navigation occured?
- Bundling the Windows Mono runtime with an applicat
- Windows 8.1 How to fix this obsolete code?
- Compile and build with single command line Java (L
- CosmosDB emulator can't start since port is al
Dependency Walker has many options including output-to-file options. One of these is
/oc:<path>
which writes the output to a CSV file, which is easily parsed by other tools or even just imported into a spreadsheet application.Depending on what you need the dependencies for you may actually have cross-platform tools to do this too - for example CMake fixup-bundle which can copy all the detected non-system dependencies to the location of your target (executable or shared library), even on Windows. The documentation doesn't clearly explain it but I've been using it for that purpose on a cross-platform project for a while now.
Using the
/oc:<path>
option, Dependency Walker gives you a CSV file which is easily parsed. If you also want the paths to the libraries you also need to use the-f 1
option. You might want to do this if you need to copy the libraries (e.g. to make a distributable version of an executable).Unfortunately in the output from depends.exe the paths to the libraries are converted to lowercase and the DLL name is converted to uppercase. For example,
When the library is actually located at:
There doesn't seem to be a way to get depends.exe to report the paths correctly which is shame.
Try the
/oc:FILENAME
option to depends, to write a comma-separated values file. This looks like it's easier to parse by machine than the "free-form" text file generated by the /ot:FILENAME/ option.