We are developing audio plugins which are dynamic libraries. This made it very hard to use 3rd-party libraries such as Qt, as our product DLL would search for Qt's DLL on host DAW program's executable directory, and it is impossible to install our dependent DLLs to that position (you don't know which host will be used, and host may even be installed later than the plugin).
I've made some brief search on this problem, the few answers direct me to a Microsoft technology called side-by-side assembly, and I'm almost drawn in the huge documentation and concepts on that. So my question is:
How to make my DLL to load several specific dependent DLLs located at path_to_plugin/MyPlugin_dependents/xxx.dll?
Or is there any examples to side-by-side assembly that simply do this and is much simpler than the official example?
Related
My software is written in VB6. For diagnostic purposes I need to determine the actual DLL / OCX files which are loaded and used by the application on a customer's computer.
Since VB6 DLLs (including OCX files) are COM libraries they are loaded indirectly based on information in the registry. This means it is possible that a different file is being used than what was used in development / testing environments. Sometimes in a client environment this can cause malfunctions which are hard to diagnose without this information.
(My plan is to build a diagnostic readout window in my program that shows the libraries that the program is using at that moment.)
You can use the Dependency Walker to find which DLL your program depend on.
But the OCX are not so easy to find because they are loaded at run-time based on the application dependencies and the registered components through the Windows registry. But you have to already know which OCX components your application references - from the Tools > References and all the places you call CreateObject.
There are many ways in which runtime dependencies on DLLs (or OCX files) can be established. Ideally you would need to account for all of them:
This answer is specific to VB6 but many other programming languages would work similarly.
Mechanisms which establish runtime dependencies:
At Compile time for traditional dynamically-linked libraries (DLLs which are not COM)
Files are (as their name suggests) dynamically loaded at runtime based on the linking process done at the end of compilation
This includes VB6 code which has used a statement like: Declare Function … Lib …
(In .NET this would mean calling out into “native code”)
To identify: Inspect the source code.
To identify without sources: These can be detected by a tool like Dependency Walker
At Compile time for COM DLLs
In VB6 this is known as “early binding”.
This includes VB6 code which has explicitly set a reference to a DLL or OCX.
Note that the dependency is actually on the COM class or interface GUID, and not explicitly on the DLL file itself.
To identify: These are listed in the project VBP.
To identify (alternate): If you don't have the VBP or source code, these dependencies can generally be revealed by by IMPORT statements in OLEView. You might need to look up some GUIDs from there in the registry to see what actual DLL files are used.
At Compile time for statically-linked libraries (not COM, not DLLs)
Library code is included in the EXE or DLL which is being compiled. Therefore there is no runtime dependency to anything external.
As far as I am aware, this is not possible for VB6 programs. Something like a C linker could use libraries like this. A rough equivalent in .NET would be using ILMerge to combine assemblies.
At Runtime for traditional DLLs (not COM)
DLLs can be loaded arbitrarily using Win32 API such as LoadLibrary().
To identify: You have to look at the source to know what might happen.
Alternately if you don't have the source you could use tools like Process Explorer and/or Process Monitor to observe a running instance and see what DLLs actually get loaded.
At Runtime for COM DLLs
Classes can be loaded arbitrarily using eg VB6 CreateObject() calls.
In VB6 this is known as “late binding”
Which DLL will be used to provide the class will be determined by the process’s activation context. The activation context is established by the app manifest file (if there is one) or the Windows registry otherwise (the normal default for VB6 programs).
To identify: You have to look at the source to know what might happen. You also need to know what the configuration state will be on the PC that runs the code - which DLL files are registered, assuming a manifest is not used.
Alternative for no source code: as in the case above
Important: dependencies can be chained. So really you need to "walk the links" of all the dependencies until you build up a complete mapping of what is required. Somewhere in that mapping you can draw a line between what you need to deploy and what the operating system or other runtime environment can be relied on to provide. (IMO for VB6, that line should be drawn rather liberally).
You may be thinking that all this makes the task very difficult or tedious – I totally agree. :)
I am am considering installing a dll assembly in the GAC and I don't have enough experience to know if this is the best practice for this scenario. Hopefully someone here can shed some light on me and get me pointed in the right direction.
The Scenario:
I have a library assembly that I have written. This DLL is designed to read some data from an output file of a third party software package. Once read the data is available for access to the caller of this DLL.
My company has developed four different windows form applications that use this library file to get data into the apps.
The 3rd party software manufacture has change the the way they write their output file, so I have modified my DLL to support the new features the third party is using.
Currently all the apps have been written using the dll as a private assembly.
The Update:
To update all of the applications would require a rebuild of all four apps referencing the updated dll file, then reinstall all four apps on every machine that may be running them.
If I were to change the dll to a GAC assembly, then all I would have to do is reinstall the updated dll in the GAC assemble on every machine that uses the DLL assembly.
The later option seems to be simpler, then the next time this happens, we just update the one dll in the GAC and away we go.
The Question
What is the best practice here?
This link makes me think I should not be thinking about GAC
When should I deploy my assemblies into the GAC?
And if GAC is the answer how do you go about deploying the strong named assembly so that is installed in the GAC from the setup file?
Any help is appreciated,
Mike
There are two questions that confuse me:
I read from the Microsoft website that we can not use different C runtime in the same project. Say I have a dll compiled with /MT flag, then I can not use the dll in a /MD compiled project. My question is that if I use LoadLibrary() to load the dll, is it also necessary that I have the same C Runtime? What's the potential danger if I don't?
I think with the /MT flag, the runtime is statically linked into the binary file. But for one of my dll project, I made a dll with /MT. However, when I dumpbin.exe /dependents mydll, it shows that MSVCR100.dll is a dependent. My question is that why the dll is still dependent on MSVCR100.dll?
1) No, that's not a requirement. This happens in any program, the Windows DLLs use their own CRT for example. Mixing CRTs in one program is however very dangerous and can cause very hard to diagnose problems. The Windows apis were carefully designed to avoid those problems, they never require code to release memory that was allocated in a DLL, don't use exceptions, don't use standard C++ library classes, don't depend on locale or any other kind of shared CRT state. The kind of things that go wrong when you mix. Restricting yourself to a C or COM api helps a lot to avoid these traps.
2) This will happen when you link code that was compiled with /MD. Common with .libs you link.
You stay out of trouble by always using /MD when you have DLLs in your project and compiling all code with the exact same compiler and options. Static libraries you didn't build yourself are very troublesome, avoid them.
Regarding your 2. question, the dependency is indirect. Your DLL uses a DLL which depends on MSVCR100.dll. Using Dependency walker you can see the dependency tree of your component and see which library is directly and indirectly dependent.
I have a set of utility LabVIEW VIs that make calls to a custom DLL written in C++. I'd like to package the VIs into a LabVIEW toolkit and deploy it via an installer, but am unsure about the standard practices involved in doing this where a custom DLL is involved. I've looked at VIPM for packaging the VIs, but so far I haven't found a way to generate a package and include the appropriate DLL dependencies. What is the correct way to go about generating an installer for a LabVIEW Toolkit and installing the DLL dependency for said toolkit in the correct location (where ever that may be)?
The DLLs immediately known to the system - i.e., the ones entered in the CLFN node - are added automatically.
DLLs which are used indirectly and DLLs which are determined programmatically cannot be auto-included and must be added manually to the Source files section of the respective Build rule.
I have some COM and some native dlls that are compiled for a Win CE device that I have. I would like to take a look at them, so I can create an application that references them and extends the functionality of some programs already on the device. When I open them with the Dependency Walker or Visual Studio 2008, both tell me that they are invalid DLLs. However, I'm fairly certain they are not corrupted, as I extracted them from the ROM of the device along with other files (bmps and the like) that are not corrupted. So I'm asking- are WinCE dlls fundamentally different than win32 dlls, and as such vs and depends is not reading them correctly? Or is something else going on?
Thanks
They are likely not corrupted, but tools that expect x86 images (as opposed to ARM, MIPS, etc) may give that misleading error when they encounter images compiled for a different processor. There are many similar tools which may help (PEDump and PEBrowsePro come to mind) scattered around the net, and since the PE format is portable (hence "portable executable"), one of them is bound to work.
In addition, some devices protect executables in ROM from being copied. It's possible the device corrupted your files on purpose when you copied them. A quick look in a hex editor should reveal this.
Dependency Checker will work with WinCE DLLs (I've used this quite often myself).
You can expect to get errors reported about missing dependencies, because Dependency Checker won't know where to find Coredll.dll & possibly the MFC DLLs because they aren't the same as the desktop ones. Once you educate Dependency Checker you can resolve these links too.
Otherwise, zildjohn01 is right that you sometimes can't copy executables or DLLs from the ROM of a WinCE device. It depends how the OS image is made: if the DLLs or EXEs are included as "MODULES" rather than "FILES" then you cannot copy them back off.