Shulou(Shulou.com)06/01 Report--

Multi-platform problem of Pinvoke

If you have not been exposed to how to call unmanaged dll and have not learned about the DllImportAttribute of c #, you can take a look at the following materials:

1 、 DllImportAttribute

2 、 Pinvoke

3. Extern keyword

Source of multi-platform support questions:

1. The library of c determines the platform at compile time, such as x86 or x64. A dll cannot support both x86 and x64 at run time, so if the .net program referencing it still wants to support any cpu, it can only load the c library of the corresponding platform according to the platform after running.

2. DllImport property requires input string dllName parameter, which can be relative path or absolute path, but .net property has a requirement: property argument must be constant expression, typeof expression or array creation expression of property parameter type. That is to say, the value string dllName must be constant when writing code (compile time) and cannot be passed to it at run time

3. The DllImport feature is sealed, so we can't inherit it or modify its logic to get the value of string dllName that matches the platform at runtime.

Multi-platform solution of Pinvoke 1. Bypass DllImport

InteropDotNet

This is an open source project on github, the author uses the idea of LoadLibrary (c.dll) + GetProcAddress into .net delegation to complete, for all the functions of c.dll, in fact, it has been completely separated from the DllImport features provided by .net, so it is not subject to the constraints of question 2 and 3 above, using this project, the .net program that calls c.dll can also be any cpu.

2. The author's plan

The author's scheme still uses the DllImport feature of .net. We know that DllImport will help us find and load c.dll automatically, and then probably map the external implementation method declared by DllImport to the function address of c.dll. If we load c.dll into .net program through LoadLibrary Api before we are ready to call the external method of c.dll, will DllImport stop searching c.dll and use it directly?

The experiment begins.

Put the x86 and x64 versions of c.dll in the subdirectory of the .net program, and construct them as follows:

Dotnet.exe

X86\ c.dll

X64\ c.dll

Dotnet.exe DllImport declares as follows:

[DllImport ("c.dll")]

Static extern int MethodC ()

Experimental results

If it runs by default, the exception of dll file cannot be reported, because c.dll is not found in DllImport's local program directory or system directory or in path environment.

If we check whether the current process is 32-bit or 64-bit before calling MethodC, and use the LoadLibrary function of windows api to load x86\ c.dll or x64\ c.dll into the process, we will not report an exception that the file cannot be found, and it is normal to call MethodC.

Summary of experiment

You can use the DllImport feature as always, and if you want the effect of any cpu, load its dll manually before calling the external implementation method.

The following is my implementation code, just load the correct dll in the static constructor, support automatic x86 or x64, and correctly find the unmanaged dll in asp.net

Static class MQTTAsync {private const string mqtt3a_dll = "paho-mqtt3a.dll"; [DllImport (mqtt3a_dll, CallingConvention = CallingConvention.Cdecl)] public static extern MqttError MQTTAsync_connect (IntPtr handle, ref MQTTAsync_connectOptions options); [DllImport ("kernel32")] private static extern IntPtr LoadLibraryA ([MarshalAs (UnmanagedType.LPStr)] string fileName) Static MQTTAsync () {var dllFile = Path.Combine (Environment.Is64BitProcess? "x64": "x86", mqtt3a_dll); if (HttpContext.Current! = null) {dllFile = Path.Combine ("~\\ bin", dllFile); dllFile = HttpContext.Current.Server.MapPath (dllFile);} MQTTAsync.LoadLibraryA (dllFile);}}

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.