CLSCompliant(true) 拖入未使用的引用

Question

任何人都可以解释以下行为吗？

总之，如果您在 Visual Studio 2008 中创建多个符合 CLS 的库并让它们共享一个公共命名空间根，则引用另一个库的库将需要引用该库的引用，甚至尽管它不会消耗它们。

用一句话来解释是相当困难的，但这里有重现该行为的步骤（密切注意命名空间）：

创建一个名为 LibraryA 的库，并向该库添加单个类：

namespace Ploeh
{
    public abstract class Class1InLibraryA
    {
    }
}

确保该库符合 CLS，方法是将 [程序集：CLSCompliant(true)] 添加到 AssemblyInfo.cs。

创建另一个名为 LibraryB 的库并引用 LibraryA。 将以下类添加到 LibraryB：

namespace Ploeh.Samples
{
    public class Class1InLibraryB : Class1InLibraryA
    {
    }
}

并

namespace Ploeh.Samples
{
    public abstract class Class2InLibraryB
    {
    }
}

确保 LibraryB 也符合 CLS。

请注意，Class1InLibraryB 派生自 LibraryA 中的类型，而 Class2InLibraryB 则不是。

现在创建第三个库，名为 LibraryC 并引用 LibraryB（但不引用 LibraryA）。 添加以下类：

namespace Ploeh.Samples.LibraryC
{
    public class Class1InLibraryC : Class2InLibraryB
    {
    }
}

这应该仍然可以编译。 请注意，Class1InLibraryC 派生自 LibraryB 中的类，不使用 LibraryA 中的任何类型。

另请注意，Class1InLibraryC 是在名称空间中定义的，该名称空间是 LibraryB 中定义的名称空间层次结构的一部分。

到目前为止，LibraryC 没有对 LibraryA 的引用，并且由于它没有使用 LibraryA 中的类型，因此该解决方案可以编译。

现在也使 LibraryC CLS 兼容。 突然，该解决方案不再编译，并给出以下错误消息：

类型“Ploeh.Class1InLibraryA”是在未引用的程序集中定义的。 您必须添加对程序集“Ploeh, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null”的引用。

您可以通过以下方式之一重新编译解决方案：

• 从 LibraryC 中删除 CLS 合规性
• 添加对 LibraryA 的引用（尽管您不需要它）
• 更改 LibraryC 中的命名空间，使其不属于 LibraryB 的命名空间层次结构的一部分（例如 更改为 Fnaah.Samples.LibraryC)
• 更改 Class1InLibraryB 的命名空间（即 LibracyC 中未使用的命名空间），使其不位于 LibraryC 的命名空间层次结构中（例如更改为 Ploeh.Samples.LibraryB）

命名空间层次结构和 CLS 合规性之间似乎存在一些奇怪的相互作用。

可以通过选择上面列表中的选项之一来解决此问题，但是任何人都可以解释此行为背后的原因吗？

Answer 1

请记住，CLS 是一组适用于生成的程序集的规则，旨在支持语言之间的互操作性。 从某种意义上说，它定义了类型必须遵循的最小公共规则子集，以确保它与语言和平台无关。 CLS 合规性也仅适用于在其定义组件之外可见的项目。

查看符合 CLS 的代码应遵循的一些准则：

• 避免使用编程语言中常用作关键字的名称。
• 不期望框架的用户能够编写嵌套类型。
• 假设不同接口上具有相同名称和签名的方法的实现是独立的。

确定 CLS 合规性的规则是：

• 当程序集未携带显式 System.CLSCompliantAttribute 时，应将其
  假定携带 System.CLSCompliantAttribute(false)。
• 默认情况下，类型继承其封闭类型（对于嵌套类型）的 CLS 合规性属性，或获取附加到其程序集的合规性级别（对于顶级类型）。
• 默认情况下，其他成员（方法、字段、属性和事件）继承其类型的 CLS 合规性。

现在，就编译器而言，（CLS 规则 1）它必须能够将 CLS 合规性规则应用于将导出到程序集外部的任何信息，并且如果该类型的所有信息都是公开的，则认为该类型是 CLS 合规性的。可访问部分（可用于在另一个程序集中执行的代码的那些类、接口、方法、字段、属性和事件）要么

• 具有仅由符合 CLS 的类型组成的签名，要么
• 被专门标记为不符合 CLS。

根据 CTS 规则，作用域只是名称的组/集合，并且在作用域内，名称可以引用多个实体，只要它们属于不同类型（方法、字段、嵌套类型、属性、事件）或具有不同的签名。 命名实体的名称恰好位于一个范围内，因此为了识别该条目，必须应用范围和名称。 范围限定名称。

由于类型被命名，类型的名称也被分组到范围中。 要完全标识类型，类型名称必须由范围限定。 类型名称的范围由包含该类型的实现的程序集限定。

对于符合 CLS 的范围，所有名称都必须是不同的，独立于种类，除非名称相同并通过重载解析。 换句话说，虽然 CTS 允许单一类型对字段和方法使用相同的名称，但 CLS 不允许（CLS 规则 5）。

更进一步，符合 CLS 的类型不得要求实现不符合 CLS 的类型（CLS 规则 20），并且还必须从另一个符合 CLS 的类型继承（CLS 规则 23）。

如果一个程序集范围内的实现引用了另一程序集范围内或由另一程序集拥有的资源，则该程序集可以依赖于其他程序集。

• 对其他程序集的所有引用都在当前程序集范围的控制下解析。
• 始终可以确定特定实现在哪个程序集范围中运行。源自该程序集范围的所有请求都相对于该范围进行解析。

所有这一切最终意味着，为了验证类型的 CLS 合规性，编译器必须能够验证该类型的所有公共部分也符合 CLS。 这意味着它必须确保名称在某个范围内是唯一的，它自己的实现部分不依赖于不符合 CLS 的类型，并且它继承自其他也符合 CLS 的类型。 这样做的唯一方法是检查该类型引用的所有程序集。

请记住，Visual Studio 中的生成步骤本质上是执行 MSBuild 的 GUI 包装器，最终只不过是调用 C# 命令行编译器的脚本方式。 为了使编译器验证类型的 CLS 合规性，它必须知道并能够找到类型引用的所有程序集（而不是项目）。 由于它是通过 MSBuild 并最终通过 Visual Studio 调用的，因此 Visual Studio (MSBuild) 向其通知这些程序集的唯一方法是将它们作为引用包含在内。

显然，由于编译器能够发现它“缺少”引用，以便验证 CLS 合规性并成功编译，因此如果它能够代表我们自动包含这些引用，那就太好了。 这里的问题是确定要包含哪个版本的程序集以及该程序集在文件系统上的位置。 通过强制开发人员提供该信息，编译器有助于保证为其提供正确的信息。 这还有一个副作用，即确保在构建过程中将所有依赖程序集复制到 Debug/bin 或 Release/bin 文件夹，以便在构建时它们位于正确的目录中。应用程序在编译后运行。

Answer 2

我查看了 CLS 的官方文档 (http://msdn.microsoft .com/en-us/netframework/aa569283.aspx），但在我找到一个简单的答案之前我的头就爆炸了。

但我认为基础是编译器为了验证LibraryC的CLS合规性，需要调查与LibraryA可能的命名冲突。

编译器必须验证“在定义程序集外部可访问或可见的类型的所有部分”（CLS 规则 1）。

由于公共类 Class1InLibraryC 继承 Class2InLibraryB，它还必须验证 LibraryA 的 CLS 合规性，特别是因为“Ploeh.*”现在在 CLS 规则 5 的“范围内”“在符合 CLS 的范围中引入的所有名称都应是不同的独立的”的种类”。

更改 Class1InLibraryB 或 Class1InLibraryC 的命名空间，使它们变得不同，似乎可以让编译器相信不再有名称冲突的机会。

如果您选择选项 (2)，添加引用并编译，您将看到该引用实际上并未在生成的程序集元数据中标记，因此这只是编译/验证时依赖项。

Answer 3

此问题已在 Roslyn 中修复，可在 Visual Studio 14 中使用。
截至 2014 年 7 月，当前的 CTP 可在此处获取。
请参阅此错误报告< /a> 了解详细信息。