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理解
有以下几个值可以使用：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函数，有可能覆盖掉线程的错误代码。