这个问题在某种程度上是对一篇相关文章的说明，我相信下面的例子描述了问题的本质。
class Program
{
public static IList<string> GetData(string arg)
{
return new string[] {"a", "b", "c"};
}
static void Main(string[] args)
{
var arg1 = "abc";
var res1 = GetData(arg1);
Console.WriteLine(res1.Count());
dynamic arg2 = "abc";
var res2 = GetData(arg2);
try
{
Console.WriteLine(res2.Count());
}
catch (RuntimeBinderException)
{
Console.WriteLine("Exception when accessing Count method");
}
IEnumerable<string> res3 = res2;
Console.WriteLine(res3.Count());
}
}
对GetData的第二次调用仅仅因为GetData接收到一个转换为dynamic的参数而引发异常，这不是很糟糕吗？方法本身可以使用这样的参数：它将其视为字符串并返回正确的结果。但结果又被强制转换为动态，结果数据突然无法根据其底层类型进行处理。除非它被显式地转换回静态类型，正如我们在示例的最后几行中看到的那样。
我不明白为什么必须这样实施。它打破了静态和动态类型之间的互操作性。一旦使用了动态，它就会感染调用链的其他部分，可能会引发类似这样的问题。
更新。有些人指出，Count()是一个扩展方法，它没有被识别是有道理的。然后，我将调用res2.Count()更改为res2.Count(从一个扩展方法更改为Ilist的一个属性)，但程序在同一个地方引发了相同的异常！这很奇怪。
UPDATE2.flq指出了Eric Lippert关于这个主题的博客文章，我相信这篇文章为它为什么以这种方式实现提供了充分的理由：http://blogs.msdn.com/b/ericlippert/archive/2012/10/22/a-method-group-of-one.aspx
您将如何在运行时定位扩展方法？关于哪些是"在作用域中"的信息基于正在编译的特定文件中的"using"语句。但是，这些并没有包含在运行时编译的代码中。它是否应该在所有加载的程序集中查看所有可能的扩展方法？项目引用但尚未加载的程序集如何处理？如果您试图允许动态使用扩展方法，会出现数量惊人的边界情况。
在这种情况下，正确的解决方案是以非扩展形式调用静态方法：
Enumerable.Count(res2)
或者，既然您知道在这种情况下是IList<T>，那么只需使用Count属性：
res2.Count<---EDIT：这不起作用，因为当由数组实现时，它是一个显式实现的接口属性。
再看看你的问题，我发现真正的问题不是关于扩展方法解析本身，而是为什么它不能确定有一个单一的方法解析是可能的，因此静态地知道类型。我还得多考虑一下，但我猜这是一个类似的边界情况问题，尤其是当你开始考虑多个重载时。
这里有一个在一般情况下可能出现的讨厌的边界情况(尽管不直接适用于您的情况，因为您是从Object派生的)。
假设您在程序集a中有一个基类Base。在程序集B中也有一个类Derived:Base。在Derived类中，您有来自上面的代码，并且您认为GetData只有一种可能的解决方案。但是，现在假设发布了程序集a的新版本，该版本具有受保护的具有不同签名的GetData方法。您的派生类继承了这一点，DLR尽职尽责地允许动态绑定到这个新方法。突然间，返回类型可能与您所设想的不同。请注意，所有这些都可以在不重新编译程序集B的情况下发生。这意味着运行前编译器不能假设DLR将解析为运行前编译器认为是唯一选项的类型，因为运行时的动态环境可能会产生不同的类型。