Build-Time Dependencies | advanced topics | home |
This topic generally does not apply when you are building an application manifest or performing an automatic build. The text is written with the assumption that you have a problem with building an assembly. Nevertheless, the techniques described here are also helpful if you isolated an application and it does not work.
When building assemblies, Manifest Maker does not know what other COM objects or DLLs will be available on the target machine when the assembly is actually used. To avoid creating hidden dependencies that will make the assembly not work, Manifest Maker hides all COM objects from the DLLs included in the assembly. When the assembly DLLs are then loaded by Manifest Maker they may fail to initialize because of missing DLLs or COM objects that they need to load.
To accommodate this Manifest Maker allows you to define what resources should be made available during the assembly build.
The first place to look is the installation procedure for the product in question. Just look at the list of files installed by the standard setup and check if all DLLs are available to the DLLs being packaged in this assembly. If they are not in the Manifest Files list (top) and not in the Build-Time Dependencies (bottom list), they are not available.
If the DLL or the application for which this DLL is intended is build by in-house developers - talk to them, they should know.
If all else fails - investigate yourself...
Some DLLs are used very frequently. So frequently, that some users of Manifest Maker always add them to the Build-Time Dependencies list.
Microsoft Windows SDK ( free download from Microsoft) includes a module dependency viewer called depends.exe. This is an indispensable tool for finding missing DLL dependencies required by somebody else's code. When you are the developer of the code being packaged, you know what DLLs and COM objects are required. Not necessarily so with third party software. Use Dependency Viewer.
The moment you open a DLL or an executable in Dependency Viewer, it recursively scans import tables and locates all imported DLLs and exported and imported entry points. The first thing you should do is ignore all missing delay-load imports and, in most cases, all error messages pertaining to Windows DLLs.
Look for yellow marks at all non-system DLLs. These are all required to load the DLLs.
If there are no more missing DLLs in the UI, there may be DLLs loaded dynamically at runtime - proceed to round two.
You may need to actually run the program or load the DLL inside depends.exe to allow the program check run-time load requests. If you need to find missing DLLs for an executable - run that program with appropriate parameters. If you are investigating a DLL (for a shared or private assembly, for example) run REGSVR32.EXE <your DLL path>.
The log window displays in red failing DLL loads and entry point lookup calls - study the list. Every failing LoadLibrary* loading a DLL with no path can be fixed - just add the DLL to run-time dependencies or the manifest, whichever is appropriate. Any DLLs loaded with an explicit path must be in that explicitly named directory - no manifest will help here.
Dependency Viewer is a great tool for finding missing DLLs, but it does not help much with missing COM objects. The most common error you will see is Class not registered. This means that the code being executed requested a COM object and COM could not find the object definition.
As we said elsewhere Windows will look for a class first in the activation context (the sum of all loaded manifests) then in the registry. If you see Windows look for any class in the registry - that class is not in the manifest.
Exception: Windows XP has bugs that sometimes make it try the registry first or only try the registry. This has been fixed in Windows XP SP1 with hotfix KB843524 and in SP2. This hotfix may not be available on Microsoft web site - call PSS and ask for it by name.
The tool to use here is Process Monitor (Procmon.exe) from Microsoft TechNet's SysInternals.
This is an outstanding tool for monitoring registry usage by applications.
The procedure is:
The identifiers in curly braces that look somewhat like this {0CD7A5C0-9F37-11CE-AE65-08002B2E1262} are class IDs. A failed attempt to open one of these will generate the above Class not registered error.
!load logexts !help !logc e * !logo e v !loge g