C#引用第三方dll文件

C#引用第三方dll文件，引用文件聲明中參數說明，總結下（以下是看的信息總結下來，我只是搬運工。。）

        [DllImport("Sdtapi.dll", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.StdCall,SetLastError = false)]
        public static extern int InitComm(int Port);

參數說明：(1)CharSet (2)CallingConvention (3)SetLastError

1.CharSet

CharSet 應該指定的是字符編碼，取值:
CharSet = CharSet.Ansi
CharSet = CharSet.Auto

2.C# 導入dll時CallingConvention的設置問題

C#調用非托管的.dll文件方法如下：(參考地址:https://www.xuebuyuan.com/645807.html)

 [DllImport("XORDll.dll",
            EntryPoint = "OutEncrypt",
            CharSet = CharSet.Ansi,
            CallingConvention = CallingConvention.StdCall)  
         ]

        public static extern int OutEncrypt(string FilePath, string SecretWord); 
其中CallingConvention.就有五種方式：

CallingConvention = CallingConvention.StdCall
CallingConvention = CallingConvention.Cdecl
CallingConvention = CallingConvention.FastCall
CallingConvention = CallingConvention.ThisCall
CallingConvention = CallingConvention.Winapi

CallingConvention理解

  CallingConvention理解

有以下幾個值可以使用：Cdecl, FastCall, StdCall, ThisCall, Winapi.

Cdecl：由調用者清理棧資源。非常適合用在可變參數的函數調用上，例如printf.

FastCall： Calling convention不支持。

StdCall：由被調用者清理棧資源。這是調用native函數時默認的方式。

ThisCall：第一個參數是this指針，會被存儲在ECX寄存器里，而其它的參數會被壓棧。這種方式通常用在調用未托管的DLL的方法或類。

Winapi：實際上並不是一個calling convention，實際上會被默認的平台的calling convention替代。例如window上調用，會替換成StdCall，Windows CE.NET上則被替換成Cdecl.

小例子：

using namespace System;
using namespace System::Runtime::InteropServices;
public ref class LibWrap
{
public:

   // CallingConvention.Cdecl must be used since the stack is 
   // cleaned up by the caller.
   // int printf( const char *format [, argument]... )

   [DllImport("msvcrt.dll",CharSet=CharSet::Unicode, CallingConvention=CallingConvention::Cdecl)]
   static int printf( String^ format, int i, double d );

   [DllImport("msvcrt.dll",CharSet=CharSet::Unicode, CallingConvention=CallingConvention::Cdecl)]
   static int printf( String^ format, int i, String^ s );
};

int main()
{
   LibWrap::printf( "\nPrint params: %i %f", 99, 99.99 );
   LibWrap::printf( "\nPrint params: %i %s", 99, "abcd" );
}

3.SetLastError

參考博客園問題：https://q.cnblogs.com/q/75565/

在調用win32 API時，會用到DllImport特性類，該類中有一個屬性是SetLastError，文檔在此：

https://msdn.microsoft.com/zh-cn/library/system.runtime.interopservices.dllimportattribute.setlasterror(v=vs.80).aspx

我對該屬性大概的理解是，如果將它設為true，那么會在api函數執行完成后調用SetLastError這個API，將api函數執行期間發生的錯誤代碼set到調用者的線程中，調用者可以通過調用Marshal.GetLastWin32Error()來獲知api函數返回的錯誤。

但問題是我嘗試把SetLastError設為false，通過傳入錯誤的參數故意令api函數出錯，隨后我仍然通過Marshal.GetLastWin32Error()得到了錯誤碼，設為true也一樣，那這樣一來，SetLastError設不設還有什么區別呢？

參考博客園的回答：

win32的錯誤代碼是使用線程本地存儲的，類似於linux下的errno，每個線程只有一個。

也就是說你使用GetLastError得到的是前面剛剛出現的錯誤代碼，如果后面再有錯誤，就會覆蓋掉這個值。

你設置這個屬性為true,CLR就會保存下這個值，后面可以使用 Marshal.GetLastWin32Error獲得使用PInvoke調用的UnManaged函數的最后一個返回值。

這個問題的關鍵就是通過PInvoke調用這幾個字，因為CLR本身也可能調用win32函數，有可能覆蓋掉線程的錯誤代碼。