C # calling the dllimport attribute in DLL (2)

Now is the time to go deeper. The dllimportattribute type plays an important role in P/invoke calls for hosted code. The main function of dllimportattribute is to instruct CLR which DLL to export the function you want to call. The DLL name is passed to dllimportattribute as a constructor parameter.

If you are not sure which DLL defines the Windows API function you want to use, the Platform SDK documentation will provide you with the best help resources. When the topic text of a Windows API function is near the end, the SDK documentation specifies the. Lib file that must be linked by the C application to use the function. In almost all cases, the. Lib file has the same name as the system DLL file defining the function. For example, if the function requires the c Application to link to kernel32.lib, the function is defined in kernel32.dll. You can find the topic of the Platform SDK documentation for messagebeep in messagebeep. At the end of the topic, you will notice that the library file is user32.lib; this indicates that messagebeep is exported from user32.dll.

Optional dllimportattribute

In addition to the host DLL, dllimportattribute also contains optional attributes, four of which are particularly interesting: entrypoint, charset, setlasterror, and callingconvention.

If you do not want the external hosting method to have the same name as the DLL export, entrypoint can set this attribute to indicate the name of the DLL function entry point for export. This is especially useful when you define two external methods that call the same unmanaged function. In addition, you can bind their serial numbers to the exported DLL Functions in windows. If you need to do this, the entrypoint values such as "#1" or "#129" indicate the serial number value of the non-hosted function in the DLL instead of the function name.

Charset is not created in all versions of Windows for character sets. Windows 9x series products lack important Unicode support, while Windows NT and Windows CE series use Unicode from the very beginning. CLR running on these operating systems uses Unicode for internal representation of string and char data. But do not worry-when you call the Windows 9x API function, the CLR automatically converts it From Unicode to ANSI.

If the DLL function does not process text in any way, you can ignore the charset attribute of dllimportattribute. However, when Char or string data is part of the equation, set the charset attribute to charset. Auto. In this way, the CLR can use the appropriate character set according to the Host OS. If the charset attribute is not explicitly set, the default value is charset. ANSI. This default value has a disadvantage because InterOP calls on Windows 2000, Windows XP, and Windows NT negatively affect the performance of text parameter messages.

Charset should be explicitly selected. ANSI or charset. the charset value of Unicode instead of charset. the only condition of auto is that you explicitly specify an export function, which is specific to one of the two Win32 OS types. The readdirectorychangesw API function is an example of this function. It only exists in Windows NT-based operating systems and only supports Unicode. In this case, you should explicitly use charset. unicode.

Sometimes, the relationship between character sets of Windows APIS is not obvious. One way to ensure that the function is correct is to check the C-Language header file of the function in the Platform SDK. (If you are not sure which header file to view, you can view the header files of each API function listed in the Platform SDK documentation .) If you find that this API function is indeed defined as a macro mapped to a function name ending with a or W, the character set is related to the function you are trying to call. An example of a Windows API function is the getmessage API declared in winuser. H. You may be surprised to find that it has a and W versions.

Setlasterror error handling is very important, but it is often forgotten during programming. When you call P/invoke, you may also face other challenges-handling the differences between Windows API error handling and exceptions in managed code. You can give me some suggestions.

If you are using P/invoke to call a Windows API function, you can use getlasterror to find the extended error information, set the setlasterror attribute to true in the dllimportattribute of the external method. This applies to most external methods.

This causes the CLR to cache errors set by API functions after each call to an external method. Then, in the packaging method, you can obtain the cached error value by calling the marshal. getlastwin32error method defined in the system. runtime. interopservices. Marshal type of the class library. We recommend that you check the expected error values from the API functions and raise a perceptible exception for these values. For all other failures (including unexpected failures. win32exception defined in the componentmodel namespace, and marshal. the value returned by getlastwin32error is passed to it. If you look back at the code in 1, you will see that this method is used in the public packaging of the extern messagebeep method.

Callingconvention the last or least important dllimportattribute described here is callingconvention. With this attribute, you can give CLR instructions on which function call conventions should be used for parameters in the stack. The default value of callingconvention. winapi is the best option. It works in most cases. However, if this call does not work, you can check the Declaration header file in the Platform SDK to see if the called API function is an abnormal API that does not conform to the call conventions.

Generally, the call conventions of local functions (such as Windows API functions or C-runtime DLL Functions) describe how to push parameters into the thread stack or clear them from the thread stack. Most Windows API functions first push the last parameter of the function into the stack, and then the called function is responsible for clearing the stack. On the contrary, many c-runtime DLL functions are defined to push them into the stack in the order in which method parameters appear in the method signature, and stack cleanup is handed over to the caller.

Fortunately, to call P/invoke, you only need to let the peripheral devices understand the call conventions. Generally, the default value callingconvention. winapi is the best choice. Then, in C Runtime DLL functions and a few functions, you may need to change the Convention to callingconvention. cdecl.