現在是更深入地進行**的時候了。在對託管**進行 p/invoke 呼叫時，dllimportattribute 型別扮演著重要的角色。dllimportattribute 的主要作用是給 clr 指示哪個 dll 匯出您想要呼叫的函式。相關 dll 的名稱被作為乙個建構函式引數傳遞給 dllimportattribute。
如果您無法肯定哪個 dll 定義了您要使用的 windows api 函式，platform sdk 文件將為您提供最好的幫助資源。在 windows api 函式主題文字臨近結尾的位置，sdk 文件指定了 c 應用程式要使用該函式必須鏈結的 .lib 檔案。在幾乎所有的情況下，該 .lib 檔案具有與定義該函式的系統 dll 檔案相同的名稱。例如，如果該函式需要 c 應用程式鏈結到 kernel32.lib，則該函式就定義在 kernel32.dll 中。您可以在 messagebeep 中找到有關 messagebeep 的 platform sdk 文件主題。在該主題結尾處，您會注意到它指出庫檔案是 user32.lib；這表明 messagebeep 是從 user32.dll 中匯出的。
可選的 dllimportattribute 屬性
除了指出宿主 dll 外，dllimportattribute 還包含了一些可選屬性，其中四個特別有趣：entrypoint、charset、setlasterror 和 callingconvention。
entrypoint 在不希望外部託管方法具有與 dll 匯出相同的名稱的情況下，可以設定該屬性來指示匯出的 dll 函式的入口點名稱。當您定義兩個呼叫相同非託管函式的外部方法時，這特別有用。另外，在 windows 中還可以通過它們的序號值繫結到匯出的 dll 函式。如果您需要這樣做，則諸如「#1」或「#129」的 entrypoint 值指示 dll 中非託管函式的序號值而不是函式名。
charset 對於字符集，並非所有版本的 windows 都是同樣建立的。windows 9x 系列產品缺少重要的 unicode 支援，而 windows nt 和 windows ce 系列則一開始就使用 unicode。在這些作業系統上執行的 clr 將unicode 用於 string 和 char 資料的內部表示。但也不必擔心 — 當呼叫 windows 9x api 函式時，clr 會自動進行必要的轉換，將其從 unicode轉換為 ansi。
如果 dll 函式不以任何方式處理文字，則可以忽略 dllimportattribute 的 charset 屬性。然而，當 char 或 string 資料是等式的一部分時，應該將 charset 屬性設定為 charset.auto。這樣可以使 clr 根據宿主 os 使用適當的字符集。如果沒有顯式地設定 charset 屬性，則其預設值為 charset.ansi。這個預設值是有缺點的，因為對於在 windows 2000、windows xp 和 windows nt® 上進行的 interop 呼叫，它會消極地影響文字引數封送處理的效能。
應該顯式地選擇 charset.ansi 或 charset.unicode 的 charset 值而不是使用 charset.auto 的唯一情況是：您顯式地指定了乙個匯出函式，而該函式特定於這兩種 win32 os 中的某一種。readdirectorychangesw api 函式就是這樣的乙個例子，它只存在於基於 windows nt 的作業系統中，並且只支援 unicode；在這種情況下，您應該顯式地使用 charset.unicode。
有時，windows api 是否有字符集關係並不明顯。一種決不會有錯的確認方法是在 platform sdk 中檢查該函式的 c 語言標頭檔案。（如果您無法肯定要看哪個標頭檔案，則可以檢視 platform sdk 文件中列出的每個 api 函式的標頭檔案。）如果您發現該 api 函式確實定義為乙個對映到以 a 或 w 結尾的函式名的巨集，則字符集與您嘗試呼叫的函式有關係。windows api 函式的乙個例子是在 winuser.h 中宣告的 getmessage api，您也許會驚訝地發現它有 a 和 w 兩種版本。
setlasterror 錯誤處理非常重要，但在程式設計時經常被遺忘。當您進行 p/invoke 呼叫時，也會面臨其他的挑戰 — 處理託管**中 windows api 錯誤處理和異常之間的區別。 可以給您一點建議。
如果您正在使用 p/invoke 呼叫 windows api 函式，而對於該函式，您使用 getlasterror 來查詢擴充套件的錯誤資訊，則應該在外部方法的 dllimportattribute 中將 setlasterror 屬性設定為 true。這適用於大多數外部方法。
這會導致 clr 在每次呼叫外部方法之後快取由 api 函式設定的錯誤。然後，在包裝方法中，可以通過呼叫類庫的 system.runtime.interopservices.marshal 型別中定義的 marshal.getlastwin32error 方法來獲取快取的錯誤值。 的建議是檢查這些期望來自 api 函式的錯誤值，並為這些值引發乙個可感知的異常。對於其他所有失敗情況（包括根本就沒意料到的失敗情況），則引發在 system.componentmodel 命名空間中定義的 win32exception，並將 marshal.getlastwin32error 返回的值傳遞給它。如果您回頭看一下圖 1 中的**，您會看到 在 extern messagebeep 方法的公共包裝中就採用了這種方法。
callingconvention 將在此介紹的最後也可能是最不重要的乙個 dllimportattribute 屬性是 callingconvention。通過此屬性，可以給 clr 指示應該將哪種函式呼叫約定用於堆疊中的引數。callingconvention.winapi 的預設值是最好的選擇，它在大多數情況下都可行。然而，如果該呼叫不起作用，則可以檢查 platform sdk 中的宣告標頭檔案，看看您呼叫的 api 函式是否是乙個不符合呼叫約定標準的異常 api。
通常，本機函式（例如 windows api 函式或 c- 執行時 dll 函式）的呼叫約定描述了如何將引數推入執行緒堆疊或從執行緒堆疊中清除。大多數 windows api 函式都是首先將函式的最後乙個引數推入堆疊，然後由被呼叫的函式負責清理該堆疊。相反，許多 c-執行時 dll 函式都被定義為按照方法引數在方法簽名中出現的順序將其推入堆疊，將堆疊清理工作交給呼叫者。
幸運的是，要讓 p/invoke 呼叫工作只需要讓外圍裝置理解呼叫約定即可。通常，從預設值 callingconvention.winapi 開始是最好的選擇。然後，在 c 執行時 dll 函式和少數函式中，可能需要將約定更改為 callingconvention.cdecl。
C 中呼叫C 的DLL
c 經過這麼多年的發展已經積累了大量的動態連線庫，如果能夠在.net環境裡應用這些函式庫，可以很大的提高整個應用的開發速度。使用c 程式設計的人員肯定對指標不會感到陌生，由於c 中的函式介面好多都可能定義成位指標，而c 中只有在宣告為unsafe code中才能夠使用指標。如果想讓c 的dll支援在...
VC中呼叫C 的DLL
在工程編譯時同步互操作註冊生成檔案。在vs中c 專案，選擇專案屬性，開啟屬性配置頁，生成頁中選擇 為com互操作註冊 核取方塊，在編譯時會同時生成tlb檔案 匯入webservices 如果類中未用到webservices，該過程可以省略，直接跳到建立c dll處即可 引用 新增服務引用 高階 新增...
C 中呼叫 除錯C 的DLL
被c 呼叫的dll一般只需要把匯出的函式 以適當的形式呈現即可呼叫，比如 extern c declspec dllexport bool integrate3 這樣的函式，在c 裡面宣告如 dllimport dll callingconvention callingconvention.stdc...