python调用dll混合模式程序集是针对

python调用dll混合模式程序集是针对,第1张

Python调用dll混合模式程序集是针对于C/C++和.NET混合编程的一种解决方案,它可以使C/C++和.NET语言之间的互 *** 作性更加容易。它可以让您在C/C++中调用.NET类库,也可以在.NET中调用C/C++函数库,从而实现跨语言的互 *** 作性。

对于 .NET 编程,Visual C++ 支持创建三种不同类型的组件和应用程序:混合类型、纯类型和可验证类型。三者都可通过 /clr(公共语言运行库编译)编译器选项来获得。

备注

有关可验证程序集的更多信息,请参见:

混合、纯 MSIL 和可验证编译模式的功能比较

如何:迁移到 /clr:pure

如何:创建可验证的 C++ 项目

如何:迁移到 /clr:safe

结合使用 SQL Server 和可验证的程序集

C++ 安全性最佳做法

混合类型 (/clr)

混合程序集(用 /clr 编译),既包含非托管部分又包含托管部分,这使得它们可以在使用 .NET 功能的同时仍包含非托管代码。这允许将应用程序和组件更新为使用 .NET 功能而不要求重写整个项目。以这种方式使用 C++ 来混合托管和非托管代码称为 C++ Interop。有关更多信息,请参见混合(本机和托管)程序集和本机和 .NET 的互 *** 作性。

纯类型 (/clr:pure)

纯程序集(用 /clr:pure 编译)既可包含本机数据类型也可包含托管数据类型,但只能包含托管函数。与混合程序集一样,纯程序集允许通过 P/Invoke 与本机 DLL 进行互 *** 作(请参见在 C++ 中使用显式 PInvoke(DllImport 属性)),但 C++ Interop 功能不可用。此外,由于纯程序集中的入口点使用 __clrcall 调用约定,纯程序集无法导出可从本机函数调用的函数。

/clr:pure 的优点

更好的性能:由于纯程序集只包含 MSIL,没有本机函数,因此不需要托管/非托管转换。(此规则的例外是通过 P/Invoke 进行的函数调用。)

AppDomain 感知度:托管函数和 CLR 数据类型存在于应用程序域内部,这影响它们的可见性和可访问性。纯程序集是可识别域的(每个类型都暗含 __declspec(appdomain)),这样从其他 .NET 组件访问它们的类型和功能更轻松、更安全。因此,与混合程序集相比,纯程序集与其他 .NET 组件的交互 *** 作更容易。

非磁盘加载:纯程序集可在内存中加载甚至进行流式处理。这对使用 .NET 程序集作为存储过程来说是很重要的。这与混合程序集的区别在于:由于混合程序集在 Windows 加载机制上的依赖项,混合程序集必须存在于磁盘上才能执行。

反射:不能在混合可执行文件上进行反射,但纯程序集提供了完整的反射支持。有关更多信息,请参见 C++ 中的反射。

承载可控性:因为纯程序集只包含 MSIL,当用于承载 CLR 并修改其默认行为的应用程序中时,与混合程序集相比,纯程序集的行为更加可预测、更加灵活。

clr:pure 的局限性

本节包含 /clr:pure 当前不支持的功能。

纯程序集无法由非托管函数调用。因此,纯程序集无法实现 COM 接口或公开本机回调。纯程序集无法通过 __declspec(dllexport) 或 .DEF 文件导出函数。此外,无法通过 __declspec(dllimport) 导入用 __clrcall 约定声明的函数。本机模块中的函数可从纯程序集调用,但纯程序集无法公开本机可调用的函数,因此在纯程序集中公开功能必须通过混合程序集中的托管函数来完成。有关更多信息,请参见如何:迁移到 /clr:pure。

在 Visual C++ 2005 中,纯模式编译不支持 ATL 和 MFC 库。

不接受纯 .netmodule 作为 C++ 链接器的输入。但是,链接器接受纯 .obj 文件,而 .obj 文件包含在 netmodule 中包含的信息的超集。有关更多信息,请参见用作链接器输入的 .netmodule 文件。

不支持编译器 COM 支持 (#import),因为这样会将非托管指令引入纯程序集中。

对于纯程序集,用于对齐和异常处理的浮点选项是不可调整的。因此,无法使用 __declspec(align)。这导致一些头文件(例如 fpieee.h)与 /clr:pure 不兼容。

当用 /clr:pure 编译时,PSDK 中的 GetLastError 函数可能发生未定义的行为。

可验证类型 (/clr:safe)

/clr:safe 编译器选项生成可验证程序集,它们类似于在 Visual Basic 和 C# 中编写的那些程序集,符合允许公共语言运行库 (CLR) 保证代码不与当前安全设置冲突的要求。例如,如果安全设置禁止某组件写入磁盘,则在执行任何代码之前,CLR 可以确定可验证组件是否满足此标准。对于可验证程序集,没有 CRT 支持。(纯程序集可通过 C 运行时库的纯 MSIL 版本获得 CRT 支持。)

与纯程序集和混合程序集相比,可验证程序集具有下列优点:

提高的安全性。

某些情况要求使用可验证程序集(例如 SQL 组件)。

Windows 的将来版本日益要求组件和应用程序是可验证的。

一个缺点是 C++ interop 功能不可用。可验证程序集无法包含任何非托管函数或本机数据类型,即使它们不是由托管代码引用的。

尽管使用了词语“safe”,但用 /clr:safe 编译应用程序并不表示不存在 bug;它只是表示 CLR 可在运行时验证安全设置。

无论程序集为什么类型,通过 P/Invoke 从托管程序集到本机 DLL 的调用将进行编译,但根据具体安全设置,在运行时可能失败。

注意

以下编码方案可以通过编译器,但会导致不可验证的程序集:使用范围解析运算符通过对象实例调用虚函数。例如:MyObj ->A::VirtualFunction()。

DllComponent.DllCacu my = new DllComponent.DllCacu()//这里有问题

实例化错误

应该是没有添加引用吧,或系统没有注册这个组件,打开 Visual Studio 2008 命令提示,用这个命令先注册一下Regasm c:\test.dll(你的dll)

Regasm.exe读取程序集中的元数据,并将所需的项添加到注册表中。注册表允许 COM 客户程序以透明方式创建 .NET Framework 类。类一经注册,任何 COM 客户程序都可以使用它,就好像该类是一个 COM 类。类仅在安装程序集时注册一次。程序集中的类实例直到被实际注册时,才能从 COM 中创建。

manifests的问题,修改原来的 manifests内容为:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<dependency>

<dependentAssembly>

<assemblyIdentity

type="win32"

name="Microsoft.VC90.CRT"

version="9.0.21022.8"

processorArchitecture="X86"

publicKeyToken="1fc8b3b9a1e18e3b"

language="*"

/>

</dependentAssembly>

</dependency>

</assembly>

参考这篇文章

http://blog.csdn.net/j88k99l00/archive/2009/08/09/4428203.aspx


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/11770162.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-18
下一篇 2023-05-18

发表评论

登录后才能评论

评论列表(0条)

保存