还有另一种方法:

class GenericFoo<T> {}

class ConcreteFoo : GenericFoo<ClassFromAnotherAssembly> {}

程序集中的代码，不引用ClassFromAnotherAssembly的程序集。

var foo = new ConcreteFoo(); //kaboom

当ClassFromAnotherAssembly是ValueTuple时，这发生在我身上。

如果使用assembly . loadfrom (String)加载程序集，并且正在引用已经使用assembly . load (Byte[])加载的程序集，也可能导致此错误。

例如，你嵌入了主应用程序的引用程序集作为资源，但你的应用程序从特定的文件夹加载插件。

你应该使用Load而不是LoadFrom。下面的代码将完成这项工作:

private static Assembly LoadAssemblyFromFile( String filePath )
{
    using( Stream stream = File.OpenRead( filePath ) )
    {
        if( !ReferenceEquals( stream, null ) )
        {
            Byte[] assemblyData = new Byte[stream.Length];
            stream.Read( assemblyData, 0, assemblyData.Length );
            return Assembly.Load( assemblyData );
        }
    }
    return null;
}

另一种可能是在依赖关系中混合发布和调试构建。例如，程序集A依赖于程序集B, A是在调试模式下构建的，而GAC中的B副本是在发布模式下构建的，反之亦然。

我在WCF服务中得到了这个，因为选择了x86构建类型，导致箱子在bin\x86下而不是bin下。选择Any CPU会导致重新编译的dll到达正确的位置(我不会详细说明这是如何发生的)。

只是补充一下我的经验，因为其他答案没有涵盖:

我在MsTest中运行单元测试时遇到了这个问题。

被测试的类位于有符号的程序集中。

该程序集的不同版本恰好在GAC中(但具有相同的程序集版本号)。

强命名程序集的依赖项解析算法与无符号程序集略有不同，因为首先检查的是GAC。

因此，MsTest正在获取GAC'd程序集，而不是使用bin文件夹中的程序集，并试图对其运行测试，这显然不起作用。

解决方案是拆除GAC总成。

注意，对我来说，提示是在运行测试时，在构建服务器上没有发生这种情况，因为构建将使用新的程序集版本号编译程序集。这意味着GAC中较旧版本的程序集将不会被拾取。

此外，我在这里找到了一个潜在的解决方案，如果您由于某种原因无法访问GAC: https://johanleino.wordpress.com/2014/02/20/workaround-for-unit-testing-code-that-reside-in-the-gac/

我也发现了同样的信息，以下是我们的发现: 我们在项目中使用第三方dll。在这些dll的新版本发布后，我们将项目更改为指向新的dll集，并成功编译。

当我试图在运行时实例化它们的一个接口类时，抛出了异常。 我们确保所有其他参考资料都是最新的，但仍然没有运气。 我们需要一段时间来发现(使用对象浏览器)错误消息中方法的返回类型是来自一个新的、未引用的程序集的全新类型。

我们向程序集添加了引用，错误就消失了。

错误消息相当误导人，但或多或少指向了正确的方向(正确的方法，错误的消息)。 即使我们没有使用有问题的方法，还是出现了异常。 这就引出了一个问题:如果在任何情况下抛出了这个异常，为什么编译器没有拾取它?