DllImport是System.Runtime.InteropServices命名空間下的一個屬性類,其功能是提供從非托管DLL(托管/非托管是微軟的.net framework中特有的概念,其中,非托管代碼也叫本地(native)代碼。與Java中的機制類似,也是先將源代碼編譯成中間代碼(MSIL,Microsoft Intermediate Language),然后再由.net中的CLR將中間代碼編譯成機器代碼。)導出的函數的必要調用信息
DllImport屬性應用于方法,要求最少要提供包含入口點的dll的名稱。
只有入口點的DLL名稱:
[DllImport("standerMFC.dll")]public static extern int PReadUID(ref HHFC_SET stru);[StructLayout(LayoutKind.Sequential)]public struct HHFC_SET{[MarshalAs(UnmanagedType.LPStr)]public String Uid;[MarshalAs(UnmanagedType.I4)] public int code;}
DllImport的定義如下:
- [AttributeUsage(AttributeTargets.Method)]??
- public?class?DllImportAttribute:?System.Attribute??
- {??
- ????public?DllImportAttribute(string?dllName)?{…}?//定位參數為dllName??
- ????public?CallingConvention?CallingConvention;?//入口點調用約定??
- ????public?CharSet?CharSet;???????????????????????????????????//入口點采用的字符接??
- ????public?string?EntryPoint;??//入口點名稱??
- ????public?bool?ExactSpelling;???//是否必須與指示的入口點拼寫完全一致,默認false??
- ????public?bool?PreserveSig;??//方法的簽名是被保留還是被轉換??
- ????public?bool?SetLastError;??//FindLastError方法的返回值保存在這里??
- ????public?string?Value?{?get?{…}?}??
- }??
用法示例:
- [DllImport("kernel32")]??
- private?static?extern?long?WritePrivateProfileString(string?section,string?key,string?val,string?filePath); ?
以上是用來寫入ini文件的一個win32api。??????????
用此方式調用Win32API的數據類型對應:DWORD=int或uint,BOOL=bool,預定義常量=enum,結構=struct。?
DllImport會按照順序自動去尋找的地方:?
1、exe所在目錄?
2、System32目錄?
3、環境變量目錄所以只需要你把引用的DLL 拷貝到這三個目錄下 就可以不用寫路徑了 或者可以這樣server.MapPath(.\bin\*.dll)web中的,同時也是應用程序中的 后來發現用[DllImport(@"C:\OJ\Bin\Judge.dll")]這樣指定DLL的絕對路徑就可以正常裝載。
????這個問題最常出現在使用第三方非托管DLL組件的時候,我的也同樣是這時出的問題,Asp.Net Team的官方解決方案如下: 首先需要確認你引用了哪些組件,那些是托管的,哪些是非托管的.
托管的很好辦,直接被使用的需要引用,間接使用的需要拷貝到bin目錄下.
非托管的處理會比較麻煩.實際上,你拷貝到bin沒有任何幫助,因為CLR會把文件拷貝到一個臨時目錄下,然后在那運行web,而CLR只會拷貝托管文件,這就是為什么我們明明把非托管的dll放在了bin下卻依然提示不能加載模塊了.
具體做法如下:
1、首先我們在服務器上隨便找個地方新建一個目錄,假如為C:\DLL
2、然后,在環境變量中,給Path變量添加這個目錄
3、最后,把所有的非托管文件都拷貝到C:\DLL中. 或者更干脆的把DLL放到system32目錄 對于可以自己部署的應用程序,這樣未償不是一個解決辦法,然而,如果我們用的是虛擬空間,我們是沒辦法把注冊PATH變量或者把我們自己的DLL拷到system32目錄的。同時我們也不一定知道我們的Dll的物理路徑。 DllImport里面只能用字符串常量,而不能夠用Server.MapPath(@"~/Bin/Judge.dll")來確定物理路徑。ASP.NET中要使用DllImport的,必須在先“using System.Runtime.InteropServices;”不過,我發現,調用這種"非托管Dll”相當的慢,可能是因為我的方法需要遠程驗證吧,但是實在是太慢了。經過一翻研究,終于想到了一個完美的解決辦法首先我們用
- [DllImport("kernel32.dll")]??
- private?extern?static?IntPtr?LoadLibrary(String?path);??
- [DllImport("kernel32.dll")]??
- private?extern?static?IntPtr?GetProcAddress(IntPtr?lib,?String?funcName);??
- [DllImport("kernel32.dll")]??
- private?extern?static?bool?FreeLibrary(IntPtr?lib); ?
分別取得了LoadLibrary和GetProcAddress函數的地址,再通過這兩個函數來取得我們的DLL里面的函數。
我們可以先用Server.MapPath(@"~/Bin/Judge.dll")來取得我們的DLL的物理路徑,然后再用LoadLibrary進行載入,最后用GetProcAddress取得要用的函數地址
以下自定義類的代碼完成LoadLibrary的裝載和函數調用
- public?class?DllInvoke???
- ????{??????????????
- ????????[DllImport("kernel32.dll")]???
- ????????private?extern?static?IntPtr?LoadLibrary(String?path); ?
- ????????[DllImport("kernel32.dll")]?????
- ????????private?extern?static?IntPtr?GetProcAddress(IntPtr?lib,?String?funcName); ??
- ????????[DllImport("kernel32.dll")]???????
- ????????private?extern?static?bool?FreeLibrary(IntPtr?lib);???????
- ??
- ????????private?IntPtr?hLib;????
- ????????public?DllInvoke(String?DLLPath)?????
- ????????{?????????????
- ????????????hLib?=?LoadLibrary(DLLPath);????
- ????????}?????????
- ??
- ????????~DllInvoke()???????
- ????????{??????????
- ????????????FreeLibrary(hLib);????
- ????????}??????????
- ??
- ????????//將要執行的函數轉換為委托????
- ????????public?Delegate?Invoke(String?APIName,Type?t)???????
- ????????{?????????????
- ????????????IntPtr?api?=?GetProcAddress(hLib,?APIName);?????
- ????????????return?(Delegate)Marshal.GetDelegateForFunctionPointer(api,t);???????
- ????????}??
- ????} ?
下面代碼進行調用
- public?delegate?int?Compile(String?command,?StringBuilder?inf);??
- ????????????//編譯??
- ????????????DllInvoke?dll?=?new?DllInvoke(Server.MapPath(@"~/Bin/Judge.dll"));??
- ????????????Compile?compile?=?(Compile)dll.Invoke("Compile",?typeof(Compile));??
- ????????????StringBuilder?inf;??
- ????????????compile(@“gcc?a.c?-o?a.exe“,inf);//這里就是調用我的DLL里定義的Compile函數??
大家在實際工作學習C#的時候,可能會問:為什么我們要為一些已經存在的功能(比如Windows中的一些功能,C++中已經編寫好的一些方法)要重新編寫代碼,C#有沒有方法可以直接都用這些原本已經存在的功能呢?答案是肯定的,大家可以通過C#中的DllImport直接調用這些功能。???
DllImport所在的名字空間 using System.Runtime.InteropServices;????
MSDN中對DllImportAttribute的解釋是這樣的:可將該屬性應用于方法。DllImportAttribute 屬性提供對從非托管 DLL?
導出的函數進行調用所必需的信息。作為最低要求,必須提供包含入口點的 DLL 的名稱。??? DllImport 屬性定義如下:
- namespace?System.Runtime.InteropServices?????
- ?{??? ??
- ?????[AttributeUsage(AttributeTargets.Method)]?????
- ?????public?class?DllImportAttribute:?System.Attribute????
- ?????{??? ???
- ?????????public?DllImportAttribute(string?dllName)??
- ?????????{...}??? ? ??
- ??
- ?????????public?CallingConvention?CallingConvention;?????
- ?????????public?CharSet?CharSet;??? ??
- ?????????public?string?EntryPoint;??? ??
- ?????????public?bool?ExactSpelling;??? ???
- ?????????public?bool?PreserveSig;??? ? ??
- ?????????public?bool?SetLastError;??? ???
- ?????????public?string?Value?{?get?{...}?}??? ??
- ?????}?????
- ?}??
1、DllImport只能放置在方法聲明上。?
2、DllImport具有單個定位參數:指定包含被導入方法的 dll 名稱的?
dllName 參數。?????
3、DllImport具有五個命名參數:??
a、CallingConvention?
參數指示入口點的調用約定。如果未指定 CallingConvention,則使用默認值?
CallingConvention.Winapi。
b、CharSet 參數指示用在入口點中的字符集。如果未指定 CharSet,則使用默認值?
CharSet.Auto。????
c、EntryPoint 參數給出 dll 中入口點的名稱。如果未指定?
EntryPoint,則使用方法本身的名稱。?????
d、ExactSpelling 參數指示 EntryPoint?
是否必須與指示的入口點的拼寫完全匹配。如果未指定 ExactSpelling,則使用默認值 false。?????
e、PreserveSig?
參數指示方法的簽名應當被保留還是被轉換。當簽名被轉換時,它被轉換為一個具有 HRESULT返回值和該返回值的一個名為 retval?
的附加輸出參數的簽名。如果未指定 PreserveSig,則使用默認值 true。?????
f、SetLastError 參數指示方法是否保留?
Win32"上一錯誤"。如果未指定 SetLastError,則使用默認值 false。?????
4、它是一次性屬性類。??????
5、此外,用 DllImport 屬性修飾的方法必須具有 extern 修飾符。
----------------------------------------------------------------------------------------------------------------------
托管代碼與非托管代碼
眾所周知,我們正常編程所用的高級語言,是無法被計算機識別的。需要先將高級語言翻譯為機器語言,才能被機器理解和運行。
在標準C/C++中,編譯過程是這樣的:
源代碼首先經過預處理器,對頭文件以及宏進行解析,然后經過編譯器,生成匯編代碼,接著,經過匯編,生成機器指令,最后將所有文件連接起來。這種編譯方式的優點在于,最終直接生成了機器碼,可以直接被計算機識別和運行,無需任何中間運行環境,但缺點也在于,由于不同平臺能夠識別的機器碼不同,因此程序的跨平臺能力較差。
而在Java語言中,源代碼并沒有被直接翻譯成機器碼,而是編譯成了一種中間代碼(字節碼Bytecode)。因此,運行Java程序需要一個額外的JRE(Java Runtime Enviromental)運行環境,在JRE中存在著JVM(Java Virtual Mechinal,Java虛擬機),在程序運行的時候,會將中間代碼進一步解釋為機器碼,并在機器上運行。
使用中間代碼的好處在于,程序的跨平臺性比較好,一次編譯,可以在不同的設備上運行。
托管/非托管是微軟的.net framework中特有的概念,其中, 非托管 代碼也叫本地(native)代碼。與Java中的機制類似,也是先將源代碼編譯成中間代碼(MSIL,Microsoft Intermediate Language),然后再由.net中的CLR將中間代碼編譯成機器代碼。而C#與Java的區別在于,Java是先編譯后解釋,C#是兩次編譯。
托管 的方式除了擁有跨平臺的優點之外,對程序的性能也產生一定的影響。但程序性能不在本文討論的范圍,這里不在贅述。此外,在.net中,C++也可以進行托管擴展,從而使C++代碼也依賴于.net和CLR運行,獲得托管代碼的優勢。
托管資源與非托管資源
在上一節中,我們講到,托管代碼與非托管代碼相比,有下列不同:
- 編譯運行過程不同
- 跨平臺能力不同
- 程序性能不同
本節中,我們會涉及到托管和非托管的另一個區別:
- 釋放資源的方式不同
在C/C++中,資源都是需要手動釋放的,比如,你new了一個指針,用過之后就需要delete掉,否則就會造成內存泄露。
而在Java中,不必考慮資源釋放的問題,Java的垃圾回收機制(GC,Garbage Collection)會保證失效的資源被自動釋放。
而C#的機制與Java類似,運行于.net平臺上的代碼,分配的資源一般會自動由平臺的垃圾回收器釋放,這樣的資源就是托管資源。
但是一些例外的資源,如System.IO.StreamReader等各種流、各種連接所分配的資源,需要顯式調用Close()或Dispose()釋放,這種資源就叫做非托管資源。
托管與非托管的混合編程
在C#的三大難點之前傳:什么時候應該使用C#?中我提到過,C#的一大優勢在于Windows平臺下的界面編程。但由于C#并不是很普及,經常出現底層或后臺代碼采用C/C++編寫的情況,此時,若選擇C#作為界面語言,則必然遇到一個C#調用C++代碼的問題。
比較普遍的解決方案就是,先將C/C++的代碼生成為DLL動態運行庫,再在C#中調用。
舉個例子
在C中:
#include
#include void DisplayHelloFromDLL()
{printf ("Hello from DLL !\n");
}void CallHelloFromDLL(char* cp)
{printf (cp);printf ("\n");*cp='a';cp++;printf (cp);printf ("\n");
}
在C#中:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;namespace TestConsole
{using System;using System.Runtime.InteropServices; // DLL supportclass Program{[DllImport(@"TestLib.dll")]public static extern void DisplayHelloFromDLL();[DllImport(@"TestLib.dll", CallingConvention = CallingConvention.Cdecl)]public static extern void CallHelloFromDLL(StringBuilder s);static void Main(){Console.WriteLine("This is C# program");DisplayHelloFromDLL();StringBuilder sb = new StringBuilder(100);CallHelloFromDLL(sb);Console.WriteLine(sb);}
}
在混合編程中,涉及了幾個要點。
- 如何在DLL中將函數接口暴露出來?
有兩種方式,一種是采用__declspec(dllexport)的聲明,另一種是編寫額外的def文件,如;導出DLL函數 LIBRARY testLib EXPORTS DisplayHelloFromDLL CallHelloFromDLL
DLL與C#之間如何進行數據傳送?
這個問題其實很復雜,像int,double這種基本的數據類型,是很好傳遞的。到了byte和char,就有點復雜了,更復雜的還有string和stringBuilder,以及結構體的傳遞等。
若傳遞的是指針,有兩種方法,一種是采用托管的方式,使用Intptr存儲指針,并使用ref獲得地址(&);另一種是在C#中編寫非托管的代碼,用unsafe聲明:unsafe { //非托管代碼 }
在非托管代碼中,即可進行指針相關的操作。
若傳遞的是函數指針,由于C#中沒有函數指針的概念,因此采用委托(delegate)的方式。?
若傳遞的是自定義結構體,也可以采用ref的方式傳遞。
這個如果有機會的話,我會單獨整理一下。extern “C”、CallingConvention =CallingConvention.Cdecl)等必要聲明。
這里面也牽涉到復雜的語言機制,本文不再贅述。
參考文獻:
[譯]C++, Java和C#的編譯過程解析
編譯原理