TypeLoadException表示'没有实现'但它被实现了

请注意 -如果这个答案对你没有帮助，请花点时间向下滚动人们添加的其他答案。

简短的回答

如果将方法添加到一个程序集中的接口，然后再添加到另一个程序集中的实现类，但在没有引用接口程序集中的新版本的情况下重新构建实现程序集中，就会发生这种情况。

在本例中，DummyItem实现了来自另一个程序集的接口。SetShort方法最近被添加到接口和DummyItem中—但是包含DummyItem的程序集是引用先前版本的接口程序集重新构建的。因此SetShort方法有效地存在，但没有将其链接到接口中的等效方法。

长回答

如果你想尝试复制这个，试试下面的方法:

1. 创建一个类库项目:InterfaceDef，只添加一个类，并构建:

   public interface IInterface
   {
   string GetString(string key);
   //short GetShort(string key);
   }
   

2. Create a second class library project: Implementation (with separate solution), copy InterfaceDef.dll into project directory and add as file reference, add just one class, and build:

   public class ImplementingClass : IInterface
   {
   #region IInterface Members
   public string GetString(string key)
   {
   return "hello world";
   }
   
   
   //public short GetShort(string key)
   //{
   //    return 1;
   //}
   #endregion
   }
   

3. Create a third, console project: ClientCode, copy the two dlls into the project directory, add file references, and add the following code into the Main method:

    IInterface test = new ImplementingClass();
   string s = test.GetString("dummykey");
   Console.WriteLine(s);
   Console.ReadKey();
   

4. Run the code once, the console says "hello world"

5. Uncomment the code in the two dll projects and rebuild - copy the two dlls back into the ClientCode project, rebuild and try running again. TypeLoadException occurs when trying to instantiate the ImplementingClass.

除了提问者自己已经说过的答案之外，还有以下几点值得注意。发生这种情况的原因是，类可能拥有与接口方法具有相同签名的方法，而无需实现该方法。下面的代码说明:

public interface IFoo
{
void DoFoo();
}


public class Foo : IFoo
{
public void DoFoo() { Console.WriteLine("This is _not_ the interface method."); }
void IFoo.DoFoo() { Console.WriteLine("This _is_ the interface method."); }
}


Foo foo = new Foo();
foo.DoFoo();               // This calls the non-interface method
IFoo foo2 = foo;
foo2.DoFoo();              // This calls the interface method

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

当我的应用程序没有对另一个程序集的引用时，我得到了这个，该程序集定义了错误消息中的方法使用的类。运行PEVerify会给出更有用的错误:“系统无法找到指定的文件。”

另一种情况是，有符号程序集的版本不正确。这不是这种疾病的正常症状，但这是我患病的情况

• asp.net项目包含程序集A和程序集B, B是强命名的

• 程序集A使用Activator。CreateInstance加载程序集C(即没有对单独构建的C的引用)

• C是引用程序集B的较旧版本构建的

希望这能帮助到一些人，我花了很长时间才弄明白。

FWIW，当有一个配置文件重定向到引用程序集的不存在版本时，我得到了这个。融合日志为胜利而战!

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

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

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

我也有这个错误，这是由任何CPU exe引用的任何CPU程序集，反过来引用x86程序集引起的。

异常抱怨MyApp中类的一个方法。实现(任何CPU)，它派生了MyApp。接口(任何CPU)，但在fuslogvw.exe中，我发现了一个隐藏的“试图从MyApp加载格式不正确的程序”异常。CommonTypes (x86)，两者都使用它。

我得到了一个“钻石”形的项目依赖:

• 项目A使用项目B和项目D
• 项目B使用项目D

我重新编译了项目A而不是项目B，这允许项目B“注入”旧版本的项目D dll

当我之前在一个程序集的单元测试期间启用了代码覆盖时，我也得到了这个错误。由于某种原因，Visual Studio“缓冲”了这个特定DLL的旧版本，即使我已经更新了它以实现新版本的接口。禁用代码覆盖消除了错误。

这类问题的另一种解释涉及托管c++。

如果您试图存根使用托管c++创建的具有特殊签名的程序集中定义的接口，您将在创建存根时得到异常。

对于Rhino mock和任何使用System.Reflection.Emit的mock框架都是如此。

public interface class IFoo {
void F(long bar);
};


public ref class Foo : public IFoo {
public:
virtual void F(long bar) { ... }
};

接口定义获得以下签名:

void F(System.Int32 modopt(IsLong) bar)

注意，c++类型long映射到System.Int32(或在c#中简单地称为int)。是有点模糊的modopt导致了问题正如Ayende Rahien在犀牛嘲笑邮件列表中所说的那样。

如果使用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;
}

我在重命名一个由ASP依赖的项目(和程序集名称)时遇到了这个问题。网络项目。类型在依赖程序集中实现了接口。尽管从“生成”菜单执行“清洁解决方案”，但具有先前名称的程序集仍然保留在bin文件夹中，并且当我的web项目执行时

var types = AppDomain.CurrentDomain.
GetAssemblies().
ToList().
SelectMany( s => s.GetTypes() /* exception thrown in this call */ )
;

上面的异常被抛出，抱怨实现web类型中的接口方法实际上没有实现。手动删除web项目的bin文件夹中的程序集解决了这个问题。

我在以下场景中收到此错误。

• 程序集A和程序集B都引用了System.Web.Mvc Version 3.0.0.0
• 程序集A引用程序集B，并拥有实现程序集B接口的类，这些类的方法返回来自System.Web.Mvc的类。
• 程序集A升级到System.Web.Mvc版本4.0.0.0
• 程序集C运行下面的代码(FertPin.Classes。Contact包含在Assembly A):

var target = Assembly.GetAssembly(typeof(FertPin.Classes.Contact));

对我来说，修复是将程序集B中的System.Web.Mvc引用升级到4.0.0.0。现在看来很明显了!

感谢原来的海报!

这仅仅意味着实现项目在我的案例中已经过时了。重新构建了包含接口的DLL，但实现DLL陈旧。

我刚刚将一个解决方案从MVC3升级到MVC5，并开始从我的单元测试项目中收到相同的异常。

检查所有的引用寻找旧文件，最终发现我需要做一些bindingRedirects Mvc，在我的单元测试项目。

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="0.0.0.0-5.1.0.0" newVersion="5.1.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

在我的例子中，它帮助重置WinForms工具箱。

当在设计器中打开Form时，我得到了异常;然而，编译和运行代码是可能的，并且代码的行为符合预期。异常发生在从我引用的库之一实现接口的本地UserControl中。更新此库后出现错误。

这个UserControl被列在WinForms工具箱中。可能Visual Studio保留了库的一个过时版本的引用，或者在某个地方缓存了一个过时的版本。

下面是我如何从这种情况中恢复过来的:

右键单击WinForms工具箱，在上下文菜单中单击Reset Toolbox。(这将从工具箱中删除自定义项)。 < br > 在我的例子中，“工具箱”项被恢复到默认状态; . . .
1. 关闭Visual Studio 在我的例子中，Visual Studio终止了一个违反异常并中止
2. 重新启动Visual Studio .

以下是我对这个错误的看法。

添加了extern方法，但我的粘贴是错误的。DllImportAttribute被放到注释的out行。

/// <returns>(removed for brevity lol)</returns>[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool IsWindowVisible(IntPtr hWnd);

确保属性实际包含在源代码中解决了这个问题。

我一直在回想这个… 这里的许多答案都很好地解释了问题是什么，而不是如何解决它

解决方案是手动删除项目发布目录中的bin文件。它将清理所有引用，并强制项目使用最新的dll。

我不建议使用发布工具的Delete功能，因为这可能会使IIS失效。

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

我得到这个错误是因为我在框架4.5版本的程序集“C”中有一个类，在框架4.5.1版本的程序集“a”中实现了一个接口，并作为程序集“B”的基类，这也是框架4.5.1版本的程序集。系统在尝试加载程序集'B'时抛出异常。此外，我还在所有三个程序集上安装了一些针对.net 4.5.1的nuget包。由于某种原因，即使nuget引用没有显示在程序集'B'中，它也成功地构建了。

事实证明，真正的问题是程序集引用了包含接口的nuget包的不同版本，并且接口签名在不同版本之间发生了变化。

对于这个错误消息，我还有另一个深奥的解决方案。我把我的目标框架从。net 4.0升级到4.6，我的单元测试项目给了我一个“System.TypeLoadException…”当我试图构建时，没有实现”错误。它还给出了关于相同的未实现方法的第二个错误消息，说“‘BuildShadowTask’任务意外失败。”这里的建议似乎都没有帮助，所以我搜索“BuildShadowTask”，并找到MSDN上的一个帖子，这让我使用文本编辑器从单元测试项目的csproj文件中删除这些行。

<ItemGroup>
<Shadow Include="Test References\MyProject.accessor" />
</ItemGroup>

在那之后，两个错误都消失了，项目建立起来了。

我也有同样的问题。我发现我的程序集，由主程序加载，有一些引用“复制本地”设置为真。这些引用的本地副本正在同一文件夹中查找其他引用，该文件夹并不存在，因为其他引用的“Copy local”被设置为false。删除“意外”复制的引用后，错误就消失了，因为主程序被设置为寻找正确的引用位置。显然，引用的本地副本打乱了调用的顺序，因为在主程序中使用了这些本地副本而不是原始副本。

重要的信息是，出现此错误是因为缺少加载所需程序集的链接。

在我的例子中，我之前在repo外部的兄弟文件夹中引用了mylib项目——让我们称其为v1.0。

|-- myrepo
|    |-- consoleApp
|    |-- submodules
|         |-- mylib (submoduled v2.0)
|-- mylib (stale v1.0)

令人困惑的是，即使*.csproj明显是错误的，指向v1.0, Visual Studio IDE显示路径为v2.0项目! F12检查接口和类也去了v2.0版本。< / p >

编译器放入bin文件夹的程序集是v1.0版本，因此令人头疼。

IDE对我撒谎的事实让我很难意识到这个错误。

解决方案:从ConsoleApp删除项目引用并读取它们。

一般提示:从头重新编译所有程序集(如果可能的话，当然不能用于nuget包)并检查bin\debug文件夹中的datetime戳。任何过时的程序集都是你的问题。

在我的例子中，我试图使用TypeBuilder来创建类型。TypeBuilder.CreateType抛出此异常。我最终意识到，在为一个帮助实现接口的方法调用TypeBuilder.DefineMethod时，我需要将MethodAttributes.Virtual添加到属性中。这是因为如果没有这个标志，该方法不会实现接口，而是实现一个具有相同签名的新方法(即使没有指定MethodAttributes.NewSlot)。

作为补充:如果更新用于生成假程序集的nuget包，也会发生这种情况。假设您安装了一个nuget包的V1.0版本，并创建了一个假程序集“fakeLibrary.1.0.0.0.Fakes”。接下来，更新到nuget包的最新版本，比如v1.1，它向接口添加了一个新方法。Fakes库仍在寻找该库的1.0版本。只需移除假组装和再生它。如果这是问题所在，这可能会解决它。

在谷歌上，我得到了这个链接。根据@Paul McLink的评论，这两个步骤解决了这个问题。

1. 重启Visual Studio
2. 清洁，建造(重建)

和错误了。

Restart VS Plugin . sh 重启VS Plugin

我在使用Autofac和大量动态程序集加载时遇到了这个错误。

在执行Autofac解析操作时，运行库将无法加载其中一个程序集。错误消息抱怨Method 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation。在Windows Server 2012 R2虚拟机上运行时出现症状，但在Windows 10或Windows Server 2016虚拟机上出现了不。

ImplementationAssembly引用了System.Collections.Immutable 1.1.37，并包含了IMyInterface<T1,T2>接口的实现，该接口在单独的DefinitionAssembly中定义。DefinitionAssembly引用了System.Collections.Immutable 1.1.36。

IMyInterface<T1,T2>中“未实现”的方法具有类型为IImmutableDictionary<TKey, TRow>的参数，该参数在System.Collections.Immutable中定义。

在程序目录中找到的System.Collections.Immutable的实际副本是版本1.1.37。在我的Windows Server 2012 R2虚拟机中，GAC包含System.Collections.Immutable 1.1.36的副本。在Windows 10和Windows Server 2016上，GAC包含System.Collections.Immutable 1.1.37的副本。只有当GAC包含较旧版本的DLL时，才会发生加载错误。

因此，程序集加载失败的根本原因是对System.Collections.Immutable的引用不匹配。接口定义和实现具有相同的方法签名，但实际上依赖于不同版本的System.Collections.Immutable，这意味着运行时不考虑实现类与接口定义匹配。

添加以下绑定重定向到我的应用程序配置文件修复了这个问题:

<dependentAssembly>
<assemblyIdentity name="System.Collections.Immutable" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-1.1.37.0" newVersion="1.1.37.0" />
</dependentAssembly>

在最近的一次windows更新后，我收到了这个错误。我设置了一个从接口继承的服务类。该接口包含一个返回ValueTuple的签名，这是c#中的一个相当新的特性。

我所能猜到的是，windows更新安装了一个新的，但即使显式引用它，更新绑定重定向，等等…最终的结果只是将方法的签名更改为“标准”的东西。

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

我在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/

我遇到了这个问题，只有我的本地机器有问题。我们组中的其他开发人员和我的VM都没有这个问题。

最后，它似乎与“目标包”有关 Visual Studio 2017

• 打开Visual Studio安装程序
• 选择修改
• 转到顶部的第二个标签“单个组件”
• 看看你选择了哪些框架和目标包。
• 我没有选择两个最新的目标包
• 我还注意到我没有“高级ASP”。NET特性”被选中，而其他机器也被选中。
• 选择并安装了新项目，现在一切都好了。

我今天得到了这个错误。我的问题是-不做在TFS得到最新版本。服务器中是带有接口的dll，其中一个方法被修改过。我用的是一个旧的，在我的个人电脑里。如何修复:获取最新版本，重新构建

还有另一种方法:

class GenericFoo<T> {}


class ConcreteFoo : GenericFoo<ClassFromAnotherAssembly> {}

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

var foo = new ConcreteFoo(); //kaboom

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

我们的问题通过更新窗口解决了!我们的web应用程序是在。net 4.7.1和c# 7.0上。当我们在不同的窗口中进行测试时，我们了解到这个问题将通过更新窗口来解决。事实上，在windows 10(版本1703)和windows server 2012(去年没有更新)中都发现了这个问题。在更新了它们之后，问题就解决了。事实上，asp.net小版本(C:\Windows\Microsoft.NET\Framework64\v4.0.30319中的clr.dll版本的第三部分)在更新后发生了一些变化。

当我的集成测试项目试图加载一个不包含接口依赖项解析的DLL时，我遇到了这个错误:

1. 集成测试项目(参考主项目，而不是 李StructureMap) < / >
2. 主项目(引用StructureMap项目-使用 类构造函数中的接口)
3. StructureMap项目(IoC - For().Use();)

这将导致抛出错误，因为它无法找到具体的实现。我在测试配置中排除了DLL，错误消失了

对我来说，解决方案与实现接口的项目具有“COM互操作注册”属性有关。集。取消勾选这个选项为我解决了这个问题。

为我解决问题的是将以下内容添加到正在加载的程序集中的ProjectReference和/或PackageReference中:

<Private>false</Private>
<ExcludeAssets>runtime</ExcludeAssets>

这使我的项目文件看起来像这样:

<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
</PropertyGroup>


<!-- For a package -->
<ItemGroup>
<PackageReference Include="SomePackage" Version="x.x.x.x">
<Private>false</Private>
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>
</ItemGroup>


<!-- For a project -->
<ItemGroup>
<ProjectReference Include="..\SomeProject\SomeProject.csproj">
<Private>false</Private>
<ExcludeAssets>runtime</ExcludeAssets>
</ProjectReference>
</ItemGroup>
</Project>

它发生在我身上，当一个接口有一个第三方dll (MWArray)的引用，“特定版本”设置为“True”，而实现的类有一个引用相同的dll，但“特定版本”设置为“False”，所以类和接口有不同的版本引用相同的dll。

将两者设置为“特定版本”:“假”或“真”(取决于你需要什么)修复了它。

当我尝试在dot net 5中使用自定义的AssemblyLoadContext(没有AppDomain创建)和共享类型(你需要使用它来调用插件方法而没有反射)实现插件程序集加载时，我得到了这个问题。这篇文章对我没有任何帮助。以下是我解决这个问题的方法:

1. 为了允许调试插件加载没有问题-设置项目输出路径到主机应用程序bin文件夹。您将调试插件项目构建后得到的相同程序集。这可能是临时更改(仅用于调试)。
2. 要修复TypeLoadException异常，你需要将所有“契约程序集”引用的程序集加载为共享程序集(运行时程序集除外)。检查加载器上下文实现(在构造函数中加载sharedAssemblies):

public class PluginAssemblyLoadContext : AssemblyLoadContext
{
private AssemblyDependencyResolver _resolver;
        

private IDictionary<string, Assembly> _loadedAssemblies;
        

private IDictionary<string, Assembly> _sharedAssemblies;


private AssemblyLoadContext DefaultAlc;


private string _path;


public PluginAssemblyLoadContext(string path, bool isCollectible, params Type[] sharedTypes)
: this(path, isCollectible, sharedTypes.Select(t => t.Assembly).ToArray())
{
}


public PluginAssemblyLoadContext(string path, bool isCollectible, params Assembly[] sharedAssemblies)
: base(isCollectible: isCollectible)
{


_path = path;


DefaultAlc = GetLoadContext(Assembly.GetExecutingAssembly()) ?? Default;


var fileInfo = new FileInfo(_path);
if (fileInfo.Exists)
{
_resolver = new AssemblyDependencyResolver(_path);


_sharedAssemblies = new Dictionary<string, Assembly>(StringComparer.OrdinalIgnoreCase);
foreach (var a in sharedAssemblies.Distinct())
{
LoadReferencedAssemblies(a);
}


_loadedAssemblies = new Dictionary<string, Assembly>();


var assembly = LoadFromAssemblyPath(fileInfo.FullName);


_loadedAssemblies.Add(fileInfo.FullName, assembly);
}
else
{
throw new FileNotFoundException($"File does not exist: {_path}");
}
}


public bool LoadReferencedAssemblies(Assembly assembly)
{
if (assembly == null)
{
throw new ArgumentNullException(nameof(assembly));
}
if (string.IsNullOrEmpty(assembly.Location))
{
throw new NotSupportedException($"Assembly location is empty string or null: {assembly.FullName}");
}
var alc = GetLoadContext(assembly);
if (alc == this)
{
throw new InvalidOperationException($"Circular assembly loader dependency detected");
}
if (!_sharedAssemblies.ContainsKey(assembly.Location))
{
_sharedAssemblies.Add(assembly.Location, assembly);


foreach (var an in assembly.GetReferencedAssemblies())
{
var ra = alc.LoadFromAssemblyName(an);
LoadReferencedAssemblies(ra);
}
return true;
}
else
{
return false;
}
}


public IEnumerable<Type> GetCommandTypes<T>()
{
var cmdType = typeof(T);
return _loadedAssemblies.Values.SelectMany(a => a.GetTypes()).Where(t => cmdType.IsAssignableFrom(t));
}


public IEnumerable<T> CreateCommands<T>(Assembly assembly)
{
foreach (var cmdType in GetCommandTypes<T>())
{
yield return (T)Activator.CreateInstance(cmdType);
}
}


protected override Assembly Load(AssemblyName assemblyName)
{
var path = _resolver.ResolveAssemblyToPath(assemblyName);
if (path != null)
{
if (_sharedAssemblies.ContainsKey(path))
{
return _sharedAssemblies[path];
}
if (_loadedAssemblies.ContainsKey(path))
{
return _loadedAssemblies[path];
}
return LoadFromAssemblyPath(path);
}
return DefaultAlc.LoadFromAssemblyName(assemblyName);
}
}

用法:

var loader = new PluginAssemblyLoadContext(fullPath, false, typeof(IPluginCommand));
loader.CreateCommands<IPluginCommand>()...