C#编译器错误选择扩展方法，添加iText7后编译失败

我之前碰到过一模一样的情况，这个报错的核心原因是命名空间冲突引发的方法解析歧义，具体来说是iText7的内部扩展方法干扰了编译器对Linq方法的匹配：

问题根源 #

当你写Where(a.Contains)这种方法组语法时，编译器会自动查找所有名为Contains的可用方法（包括实例方法和扩展方法），尝试将其转换为Func<int, bool>委托。而iText7 7.0.4的KernelExtensions类中存在一个internal访问级别的Contains扩展方法，签名大致是：

internal static bool Contains<TKey, TValue>(this IDictionary<TKey, TValue> dict, TKey key)

虽然这个方法是内部的、你本不该访问到，但编译器在候选方法筛选阶段会把它列入考虑范围，最后因为它的访问级别不够而抛出CS0122错误。

而你用i => a.Contains(i)的lambda写法时，编译器会明确绑定到int[]（数组实现了ICollection<T>）的实例Contains方法，不会去扫描扩展方法，所以不会触发这个问题。

可行的解决方案 #

• 改用lambda表达式（最推荐）：就是你已经写好的Where(i => a.Contains(i))，写法简单直观，完全避免方法解析歧义。
• 显式指定委托类型：把方法组包装成明确的委托，让编译器直接绑定到正确的实例方法：

  var b = new[] { 1, 2 }.Where(new Func<int, bool>(a.Contains)).ToList();
  

• 显式调用Linq的静态方法：如果更倾向于静态方法的写法，可以直接调用Enumerable.Contains：

  var b = new[] { 1, 2 }.Where(item => Enumerable.Contains(a, item)).ToList();
  

• 清理不必要的命名空间：如果你的代码里没有用到iText7的某些命名空间，可以移除对应的using语句，减少扩展方法的扫描范围（不过这个方法适用性有限，毕竟安装iText7大概率需要用到它的命名空间）。

内容的提问来源于stack exchange，提问作者Inok