云南建站推广,西安有哪些好玩的,网站开发需要的技术,外贸soho网站建设DllImport是System.Runtime.InteropServices命名空间下的一个属性类#xff0c;其功能是提供从非托管DLL#xff08;托管/非托管是微软的.net framework中特有的概念#xff0c;其中#xff0c;非托管代码也叫本地#xff08;native#xff09;代码。与Java中的机制类似其功能是提供从非托管DLL托管/非托管是微软的.net framework中特有的概念其中非托管代码也叫本地native代码。与Java中的机制类似也是先将源代码编译成中间代码MSILMicrosoft 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的定义如下
代码如下:[csharp] view plaincopy[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 {…} } } 用法示例
代码如下:[csharp] view plaincopy[DllImport(kernel32)] private static extern long WritePrivateProfileString(string section,string key,string val,string filePath); 以上是用来写入ini文件的一个win32api。
用此方式调用Win32API的数据类型对应DWORDint或uintBOOLbool预定义常量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”相当的慢可能是因为我的方法需要远程验证吧但是实在是太慢了。经过一翻研究终于想到了一个完美的解决办法首先我们用
代码如下:[csharp] view plaincopy[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的装载和函数调用
代码如下:[csharp] view plaincopypublic 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); } } 下面代码进行调用
代码如下:[csharp] view plaincopypublic 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 属性定义如下代码如下:[csharp] view plaincopynamespace 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程序需要一个额外的JREJava Runtime Enviromental运行环境在JRE中存在着JVMJava Virtual MechinalJava虚拟机在程序运行的时候会将中间代码进一步解释为机器码并在机器上运行。
使用中间代码的好处在于程序的跨平台性比较好一次编译可以在不同的设备上运行。
托管/非托管是微软的.net framework中特有的概念其中
非托管
代码也叫本地native代码。与Java中的机制类似也是先将源代码编译成中间代码MSILMicrosoft Intermediate Language然后再由.net中的CLR将中间代码编译成机器代码。
而C#与Java的区别在于Java是先编译后解释C#是两次编译。
托管
的方式除了拥有跨平台的优点之外对程序的性能也产生一定的影响。但程序性能不在本文讨论的范围这里不在赘述。此外在.net中C也可以进行托管扩展从而使C代码也依赖于.net和CLR运行获得托管代码的优势。
托管资源与非托管资源
在上一节中我们讲到托管代码与非托管代码相比有下列不同
编译运行过程不同跨平台能力不同程序性能不同
本节中我们会涉及到托管和非托管的另一个区别
释放资源的方式不同
在C/C中资源都是需要手动释放的比如你new了一个指针用过之后就需要delete掉否则就会造成内存泄露。而在Java中不必考虑资源释放的问题Java的垃圾回收机制GCGarbage 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);*cpa;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#之间如何进行数据传送这个问题其实很复杂像intdouble这种基本的数据类型是很好传递的。到了byte和char就有点复杂了更复杂的还有string和stringBuilder以及结构体的传递等。若传递的是指针有两种方法一种是采用托管的方式使用Intptr存储指针并使用ref获得地址另一种是在C#中编写非托管的代码用unsafe声明unsafe
{
//非托管代码
}
在非托管代码中即可进行指针相关的操作。若传递的是函数指针由于C#中没有函数指针的概念因此采用委托delegate的方式。 若传递的是自定义结构体也可以采用ref的方式传递。这个如果有机会的话我会单独整理一下。extern “C”、CallingConvention CallingConvention.Cdecl)等必要声明。这里面也牵涉到复杂的语言机制本文不再赘述。
参考文献[译]C, Java和C#的编译过程解析编译原理
