你正在将CLR组件添加到本机项目，你的项目将被转换为具有公关语言运行时支持

对于 .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()。

楼主理解是正确的。楼主说自己试初学VC，但居然能够自己研究发现这么多信息，如果我是初学者的话，我肯定没楼主那么能干。一定会一头雾水。从这点上，我非常佩服楼主的才能！我是远远达不到这样的高度的。

至于他们给你的DLL，基本上能断定那个是CLR写的DLL。就我理解，CLR应该和MFC是完全不一样的，无论是语言的语法，或者是从CLR、MFC的基础架构方面，都没有交集！因此可以将CLR理解为一门全新的语言，它使用的库是.net 库。楼主肯定有 MFC 基础的。如果楼主研究过C#的话，那CLR应该是很容易上手的。从亲缘性方面来讲，CLR项目和C#项目更相似。它们的DLL只需要在使用DLL的项目中，通过楼主所言的“引用”方式添加进来就OK了。没有LIB的区别。它的实现机制是：所有DLL/EXE在文件内部都会有一个清单，该清单记录了DLL/EXE自己实现的类，函数以及它引用别人的类、函数和这些文件名等一系列信息。

至于有人提出是COM的关系，我认为这个问题应该和COM没有一点关系。所以如果要从COM入手，完全是一条死胡同。会浪费时间的！

虽然VC支持MFC和CLR混编，但如果要混编，我感觉系统不稳定，一方面我担心兼容性的问题导致程序的稳定性问题。另一方面，既要熟悉MFC，又要熟悉CLR，否则混编很困难。我认为，既然要用别人的CLR DLL，那么最好还是别用MFC，直接做CLR。楼主不熟悉CLR，那么只有学。尽管需要赶工期，但我也想不出好办法。做CLR项目是我认为最好的出路！

---