禁用屏幕拷贝（Print Screen)，调用派生的析构函数及其它......

核心提示： 我有一个用 C++ 写的类库，我用托管扩展将它们暴露给 .NET，禁用屏幕拷贝（Print Screen)，调用派生的析构函数及其它......(6)，某些函数使用 uint （无符整型），它与 .NET 中的 UInt32 对应，检查兼容性对你来说更有用，所以在我写此文时，后来我阅读了一

我有一个用 C++ 写的类库，我用托管扩展将它们暴露给 .NET。某些函数使用 uint （无符整型），它与 .NET 中的 UInt32 对应。后来我阅读了一些权威资料后发现 UInt32 不是“ CLS 兼容的”。这到底是什么意思啊，我要考虑这些问题吗？

.NET CLR 是运行时系统，它加载并执行托管程序集。CLR 是一个让你可以用任何你想要的语言编写基于 .NET 应用程序的系统，只要为这些语言提供了 IL 编译器。例如，C++ 有 unsigned int，C# 有 uint，但 Visual Basic .NET 现在没有等同的与无符整型对应的内建类型（到了 Visual Basic 2005 将会支持这种类型）。如果你想让对象完全与其它对象交互，而不管它们是用哪种语言实现的，那么就必须将自己约束在整个类型系统的较小的子集中。该子集由 CLS （Common Language Specification——公共语言规范）定义，在 .NET 框架文档中，你可以在“Cross-Language Interoperability——跨语言户用性”中找到这个主题，CLS 规定哪种内建类型是 CLS 兼容的。

Figure 5 是部分处理整数类型的规范。正像你所看到的，无符类型不是 CLS 兼容的。那是因为在开发框架的时候，Visual Basic 还没有内建的无符类型。

UInt32 不是 CLS 兼容的，这是什么意思呢？对于你的库来说，它又意味着什么呢？首先，CLS 规则只应用于你的程序集向外界暴露的类和方法。在内部，你可以使用语言支持的任何类型。其次，UInt32 是一个成熟的 CLR 类，这意味着任何面向 .NET 的语言，包括 Visual Basic在内，都能编译并与你的代码链接，即使它暴露使用 UInt32 的方法。如果你有一个返回 UInt32 的方法，无论是作为值返回，还是作为 [out] 参数返回，任何程序都可以接着将那个值作为输入参数传给另一个方法。但某些类似 Visual Basic 这样的语言可能无法创建无符整型。这可能是个问题，也可能不是问题，这要依赖你的应用程序而定。

一个 Visual Basic 程序总是可以传递负整数，并且当它到达你的库时，它会被作为无符对待——但此 Visual Basic 程序不能进行正确的计算，因为它将大的无符值看成是负整数。如果你需要计算并处理整个32位范围的无符整数，你应该将参数暴露为 Int64，而不是　UInt32。

你怎么知道你的程序是否是 CLS 兼容的呢？如果你用 C# 编写，你可以用 CLSCompliant 属性让编译器检查你的代码的 CLS 兼容性。你可以将 CLSComplisn 应用到整个程序集或者特定的类或方法。例如：

// mark entire assembly as CLS-compliant
[assembly:CLSCompliant(true)];

为了标记特定的类或方法是 CLS 兼容的，你得对类/方法应用这个属性。

唉！虽然 C++ 编译器识别 CLSCompliant 属性，但它无法检查兼容性。也就是说，即使你标记了它们的兼容性，C++ 编译器对于非兼容代码不会报错。有一个单独的工具叫 FxCop，这个工具就像托管程序集的绷带（应该有人知道绷带是什么东西吧），然而，FxCop 虽然功能很强，会检查并报错（比如，空析构函数，以“C”开头的类名以及变量名包含非英文字符等），但也它不检查 CLS 兼容性，检查兼容性对你来说更有用。所以在我写此文时，恐怕没有什么好办法自动检查托管 C++ 程序的 CLS 兼容性。