谁能解释以下行为?
总之,如果您在 Visual Studio 2008 中创建多个符合 CLS的库并让它们共享一个公共命名空间根,则引用另一个库的库将需要对该库的引用的引用,即使它不使用它们。
这很难用一句话来解释,但这里有一些重现行为的步骤(密切注意命名空间):
创建一个名为 LibraryA 的库并向该库添加一个类:
namespace Ploeh
{
public abstract class Class1InLibraryA
{
}
}
[assembly: CLSCompliant(true)]
通过添加到 AssemblyInfo.cs确保库符合 CLS 。
创建另一个名为 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 合规性之间似乎存在一些奇怪的相互作用。
可以通过选择上面列表中的一个选项来解决这个问题,但是任何人都可以解释这种行为背后的原因吗?