We running a .NET application that uses an unmanaged dynamic-link library (the old famous DLL), we may encountered the following error:
| Could not load file or assembly or one of its dependencies. An attempt was made to load a program with an incorrect format. |
The error indicates that the program is not able to load the assembly, but when we look at our project references, we can see the assembly exists. If we take a look at the message carefully, we can also see that the error tells us that perhaps it is not able load a dependency. But what does this really mean? To understand this, let’s first do a refresh on .NET interoperability
Interoperating with Unmanaged Code
The .NET framework provides interoperation with native C and C++ dynamic-link libraries (DLL) for common Windows API and COM components. These DLLs do not run under the .NET runtime, so this is the reason why they are called unmanaged code. Many products are still written using the native Windows API not the .NET framework. When we try to use these DLL on a .NET application, we need to first import the API using the following directives.
| using System.Runtime.InteropServices; // Use DllImport to import the Win32 MessageBox function. [DllImport("user32.dll", CharSet = CharSet.Unicode)] private static extern int MessageBox(IntPtr hWnd, string text, string caption, uint type); |
As an example, this import directive allows us to call a Windows API message box function. Off course, when using the .NET framework, we use the framework API MessageBox.Show instead of importing the native API. Use the following gist for a running example:
How does that help on resolving our missing dependency?
It is important to know how interops work with .NET because when we do a DLLImport on an DLL, we are only importing the external library methods, but we do not know if there are downstream dependencies associated to that DLL. To be able to discover our dependencies, we can use the binary file dumper (dumpbin.exe) utility by running the following command:
| dumpbin.exe /dependent myfile.dll |
Note: This utility is part of the Visual Studio installation, and it can only run under the Visual Studio command prompt not the system command prompt.
After running this command, we should be able to see a list of DLL dependencies. These DLLs should be in our system path or the local directory path. The missing unmanaged DLL are usually related to the C++ run time libraries that are installed on the system when we install Visual Studio or SDK packages.. By default, these DLLs are deployed in the system32 folder. We can search for the files listed on the output to make sure they exist. If they don’t, we have found a missing dependency, and we need to install the Visual C++ redistributable package that contains the missing DLL.
Background on Visual C++ Redistributable:
These DLLs are usually deployed by the Visual C++ redistributable packages within Visual Studio. They are part of the Windows system components for reusability, performance and memory management purposes. A big problem with these packages is that some software may have been built with an older version of Visual C++, and it may not exist on the current system. This causes the dependency problem.
To address this problem, we need to search for the missing DLL on the Microsoft web site. This should enable us to download and install the correct package. For example, the package for the Visual C++ 2005 redistributable package can be found at this location:
Conclusion;
When we start a new project that requires the use of some unmanaged DLL, we need to inspect those libraries using the dumpbin utility and make sure we have those dependencies installed on the development environment. When we deploy these solutions, we need to also remember to package those dependencies within our solution. Otherwise, the application will crash with the Unable to load assembly error.
0 comments :
Post a Comment
What do you think?