Bugs that often occur when calling unmanaged DLLs and solutions

C and C + + have a lot of good class library of precipitation, in. NET, completely discard them and start again is very unwise and unrealistic, so, we often need to use the PInvoke of the unmanaged DLLs previously left. For the experience of using unmanaged DLLs in. NET, there are at least two problems that are often encountered, which are reflected by throwing exceptions at run time.

1. Attempting to load malformed program

This exception occurs, usually. NET application is not the same as the platform of an unmanaged DLL.

In general, when using VS to develop. NET applications and class libraries, the default target platform is "any CPU", which automatically selects X86 or X64 based on the CPU type at run time because. NET compiled assemblies are based on IL, and at run time the CLR will not emit its JIT as a X86 or X64 machine code.

The DLL generated by C or C + + compilation is machine code, so the decision of its platform is decided at compile time. With the setting of the compile option, we can compile the C + + project as a X86 DLL or a X64 DLL.

So, when the unmanaged DLL is called. NET project, you also need to set its target platform properties exactly the same as the platform on which the unmanaged DLL is running. The unmanaged DLLs that are typically left behind are x86 based, so that the unmanaged DLLs are invoked. NET project, set its target platform property to "X86".

You can find this setting according to the project-> properties-> build-> target platform:

2, unable to load DLL, could not find the specified module

The run called unmanaged. NET applications can sometimes get this kind of exception, but the more depressing thing is that this anomaly is not on all computers, and in experience, it just appears on a few computers, and it's normal to run on most computers. We had this problem when we developed the Voice video recording component Mfile, and it was a headache.

If this happens, it is likely that a small number of computers did not install the VC + + runtime (CRT), or the CRT installed incorrectly caused. There are two useful solutions:

(1) Under C disk, the following documents were found: Msvcm80d.dll, Msvcp80d.dll, Msvcr80d.dll, Microsoft.VC80.DebugCRT.manifest. Copy these files to the target machine, put them under the running directory, or put them under System32.

Note that generally these files have multiple versions, located in different folders, to observe the name of their folders: x86 or x64, debug or release, and whether or not MFC, which are selected to be consistent with the information of the unmanaged DLL.

(2) If there is an unmanaged DLL source code, then modify the compilation options, recompile: The/MD or/MDD changed to/MT or/MTD, so that the VC Run-time Library to achieve the static link, in the runtime no longer need the above several DLLs.