库 A 使用 C# 扩展方法调用库 B。
我从 C# 编译器中收到一个奇怪的错误:
类型“System.Windows.Forms.Control”是在程序集中定义的
没有被引用。您必须添加对程序集的引用
'System.Windows.Forms,版本=4.0.0.0
库 A 或 B 都不依赖于System.Windows.Forms.Control
,A 也不依赖于System.Windows.Forms.Control
. System.Windows.Forms.Control
仅从同一解决方案中的另一个项目引用。
奇怪的是,如果我将调用语法更改为静态方法,它就会成功编译。
//static method syntax works fine
var leads = SourceLeadConfigurationHelper.GetLeads(enLeadSystem);
//extension method syntax cause error
//error The type 'System.Windows.Forms.Control' is defined in an assembly that is not referenced.
var leads = enLeadSystem.GetLeads();
扩展方法如下所示:
public static class SourceLeadConfigurationHelper
{
public static IList<ChannelID> GetLeads(this LeadSystem leadSystem);
public static IList<ChannelID> GetLeads(this SourceLeadConfiguration slc);
public static IList<ChannelID> GetLeads(LeadSystem leadSystem, bool throwException);
}
所以你会发现检测使用哪个扩展没有问题。LeadSystem
是一个枚举,SourceLeadConfiguration
是一个类。
我有 Visual Studio 2013 更新 5、.NET Framework 4.0。
这是对 C# 编译器行为的一致抱怨,让程序员非常抓狂。不幸的是,没有规范的问答,每个案例都是不同的。第一份报告在 VS2012/.NET 4.5 时间范围内开始出现。编译器过去并没有这样做,它听起来像是一个错误修复,其影响比预期更大。我们也没有经常听到它,大多数程序员只是按照错误消息中的指导并添加程序集引用。你也应该如此,它可以轻松解决问题。
尝试在这里描述一下它的特征。它与扩展方法没有直接关系,此行为特定于方法重载解析。扩展方法只是它的一个特例,当然是一个棘手的情况。
找到方法重载匹配并不是特别棘手,当重载不明确时,它会生成一条不错的错误消息,这才是问题所在。关于更改的行为非常清楚的一件事是编译器现在更加彻底。它坚持要知道一切关于参数的类型。即使程序员很清楚传递的参数不可能与另一个未引用的程序集中的类型匹配。但编译器对此很顽固,如果它不知道类型,那么它会坚持你添加引用。
扩展方法很棘手,因为可能有很多,而不仅仅是您(显然)期望选择的 SourceLeadConfigurationHelper.GetLeads() 。一次集会might定义其他扩展方法,它们只是might向 SourceLeadConfiguration 类型添加更多扩展方法。如果编译器知道程序集存在,但不知道它是什么样子,因此无法知道它可能包含哪些扩展方法,那么它会抱怨。请注意,这解释了为什么直接调用静态方法时不会出现错误,编译器不需要去寻找扩展。
您肯定可以猜到编译器如何找到 System.Windows.Forms 程序集。它是由另一个程序集引入的,即您提到但没有描述的程序集。诊断结果是 System.Windows.Forms.Control 类型在该程序集的元数据中泄漏。通常作为公共方法的参数或返回类型。您必须在源代码中进行一些挖掘才能找到它,否则您可以轻松消除它。
关于扩展方法的另一个细节是might与此相关的是,ExtensionAttribute 类型在 .NET 4.5 中从 System.Core.dll 移至 mscorlib.dll。这是一项相当重大的更改,并且当程序员没有正确构建程序集时会导致很多问题。如果您的目标是 .NET 4.0,那么您需要仔细检查这一点,详细信息are here https://stackoverflow.com/a/13750130/17034.
希望您能从引用 Winforms 的程序集中找到它。如果没有,或者您无法消除暴露,那么添加引用实际上就足以让编译器满意。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)