C#学习教程：TypeLoadException说“未实现”，但已实现错误是：System.TypeLoadException：程序集“ActiveViewers(...)”中类型“DummyItem”中的方法“SetShort”没有实现。我只是不明白为什么。SetShort存在于DummyItem类中，我什至重新编译了一个写入事件日志的版本，只是为了确保它不是部署/版本控制问题。奇怪的是调用代码甚至没有调用SetShort方法。注意-如果此答案对您没有帮助，请花点时间向下滚动以查看人们添加的其他答案。简短回答如果您将方法添加到一个程序集中的接口，然后将其添加到另一个程序集中的实现类，但重建实现程序集而不引用接口程序集的新版本，就会发生这种情况。在这种情况下，DummyItem实现来自另一个程序集的接口。SetShort方法最近被添加到接口和DummyItem-但包含DummyItem的程序集被重新引用，引用接口程序集的先前版本。所以SetShort方法确实存在，但是没有神奇的方法将它连接到接口中的等效方法。长答案如果你想重现这个功能，试试这个：创建一个类库项目：InterfaceDef，只添加一个类，然后构建：publicinterfaceIInterface{stringGetString(stringkey);//短GetShort(字符串键);}创建第二个类库项目：Implementation（使用单独的解决方案），将InterfaceDef.dll复制到项目目录并作为文件引用添加，只添加一个类，构建：publicclassImplementingClass:IInterface{#regionIInterfaceMemberspublic字符串GetString（字符串键）{返回“你好世界”；}//publicshortGetShort(stringkey)//{//返回1;//}#endregion}创建第三个控制台项：ClientCode，将两个dll复制到项目目录下，添加文件引用，并在Main方法中添加如下代码：IInterfacetest=newImplementingClass();strings=test.GetString("dummykey");控制台.WriteLine(s);控制台.ReadKey();运行代码一次，控制台显示“helloworld”取消注释两个dll项目中的代码并重建-将两个dll复制回ClientCode项目，重建并再次尝试运行。尝试实例化ImplementingClass时发生TypeLoadException。除了提问者自己的回答，以下几点可能也值得注意。发生这种情况的原因是因为类可以使用与接口方法具有相同签名的方法而无需实现该方法。以下代码说明：publicinterfaceIFoo{voidDoFoo();}publicclassFoo:IFoo{publicvoidDoFoo(){Console.WriteLine("这_不是_接口方法。");}voidIFoo.DoFoo(){Console.WriteLine("This_is_theinterfacemethod.");}}Foofoo=newFoo();foo.DoFoo();//这调用了非接口方法IFoofoo2=foo;foo2.DoFoo();//当我的应用程序没有引用另一个程序集时，这调用了我得到的接口方法，该程序集定义了错误消息中使用的方法的定义类。运行PEVerify会产生一个更有帮助的错误：“系统找不到指定的文件。”我遇到了同样的消息，这是我们发现的：我们在我们的项目中使用了第三方dll。新版本发布后，我们将项目更改为指向新的一组dll，并成功编译。当我尝试在运行时设置接口类之一时抛出异常。我们确保所有其他参考资料都是最新的，但仍然没有运气。我们花了一段时间才发现（使用对象浏览器）错误消息中方法的返回类型是来自新的未引用程序集的全新类型。我们添加了对程序集的引用，错误消失了。我在以下情况下收到此错误。vartarget=Assembly.GetAssembly(typeof(FertPin.Classes.Contact));我的解决方法是将程序集B中的System.Web.Mvc引用升级到4.0.0.0。现在看起来很明显！感谢楼主的原创！另一方面，如果签名程序集的版本不正确，则可能会出现此错误。这不是这个原因的正常症状，但这就是我得到它的方式希望对某人有所帮助-我花了很多时间试图解决这个问题。我也有这个错误，它是由引用任何CPU程序集的任何CPU引用引起的x86程序集引起的。异常抱怨MyApp.Implementations(AnyCPU)中的一个类的方法，它派生自MyApp.Interfaces(AnyCPU)，但是在fuslogvw.exe中，我发现MyApp隐藏了“尝试加载程序不是格式正确”异常。两者都使用CommonTypes(x86)。我得到了一个“菱形”形状的项目依赖项：我重新编译了项目A而不是项目B，它允许项目B“注入”我在重命名项目（和程序集）时遇到的项目Ddll的旧版本name)问题，这是一个依赖于ASP.NET的项目。Web项目中的类型在依赖程序集中实现接口。尽管从构建菜单执行清理解决方案，但具有以前名称的程序集仍保留在bin文件夹中，并且当我的Web项目执行时vartypes=AppDomain.CurrentDomain.GetAssemblies().ToList().SelectMany(s=>s.GetTypes()/*在这个调用中抛出异常*/);抛出上面的异常，报错说实现web类型中的接口方法并没有真正实现。手动删除Web项目的bin文件夹中的程序集解决了这个问题。我一直回到这里……这里的许多答案都很好地解释了问题是什么，而不是如何解决问题。解决办法是手动删除项目发布目录下的bin文件。它将清除所有引用并强制项目使用最新的DLL。我不建议使用发布工具来删除功能，因为这往往会丢弃IIS。对于此错误消息，我有另一个深奥的解决方案。我将我的目标框架从.Net4.0升级到4.6，当我尝试构建时，我的单元测试项目出现“System.TypeLoadException...isnotimplemented”错误。它还为同一个未实现的方法提供了第二条错误消息，“'BuildShadowTask'任务意外失败。”这里的建议似乎都没有帮助，所以我搜索“BuildShadowTask”并在MSDN上找到了一篇帖子让我使用文本编辑器从单元测试项目的csproj文件中删除这些行。之后，这两个错误消失并构建了项目。我在使用Autofac和大量动态程序集加载的上下文中遇到此错误。在执行Autofac解析操作时，运行时将无法加载其中一个程序集。错误消息抱怨程序集“ImplementationAssembly”中类型“MyType”中的方法“MyMethod”没有实现。在WindowsServer2012R2VM上运行时会出现症状，但在Windows10或WindowsServer2016VM上不会出现症状。ImplementationAssembly引用System.Collections。Immutable1.1.37，并包含IMyInterface接口的IMyInterface实现，它位于单独的DefinitionAssembly中。DefinitionAssembly引用System.Collections.Immutable1.1.36。IMyInterface中的“未实现”方法具有IImmutableDictionary类型，它在System.集合。不可变的。在程序目录中找到的System.Collections.Immutable的实际副本是版本1.1.37。在我的WindowsServer2012R2VM上，GAC包含System.Collections.Immutable1.1.36的副本...在Windows10和WindowsServer2016上，GAC包含System.Collections.Immutable1.1.37的副本。只有当GAC包含旧版本的DLL时才会发生加载错误。因此，程序集加载失败的根本原因是对MismatchedreferencetoSystem.Collections.Immutable的引用。接口定义和实现具有相同的方法签名，但实际上依赖于不同版本的System.Collections.Immutable，这意味着运行时不会考虑实现类来匹配接口定义。将以下绑定重定向添加到我的应用程序配置文件解决了这个问题：当我之前在我的一个程序集的单元测试期间启用代码覆盖时，我也遇到了这个错误。出于某种原因，VisualStudio“缓存”了这个特定DLL的旧版本，即使我已经更新它以实现接口的新版本。禁用代码覆盖可以消除错误。托管C++对此类问题的另一种解释。如果您尝试对使用托管C++创建的程序集中定义的接口存根，并带有特殊签名，则在创建存根时会出现异常。这适用于RhinoMocks以及可能使用System.Reflection.Emit的任何模拟框架。公共接口类IFoo{voidF(longbar);};publicrefclassFoo:publicIFoo{public:virtualvoidF(longbar){...}};接口定义获得以下签名：voidF(System.Int32modopt(IsLong)bar)请注意，C++类型long映射到System.Int32（或在C#中简称为int）。正如AyendeRahien在RhinoMocks邮件列表中所述，导致问题的原因是一些晦涩的modopt。如果使用Assembly.LoadFrom(String)加载程序集并引用已使用Assembly.Load(Byte[])加载的程序集，也可能导致此错误。例如，您的主应用程序将嵌入式程序集作为资源引用，但您的应用程序从特定文件夹加载插件。应该使用Load而不是LoadFrom。以下代码将完成这项工作：privatestaticAssemblyLoadAssemblyFromFile(StringfilePath){using(Streamstream=File.OpenRead(filePath)){if(!ReferenceEquals(stream,null)){Byte[]assemblyData=newByte[stream。长度];stream.Read(assemblyData,0,assemblyData.Length);返回Assembly.Load(assemblyData);}}返回空值；我刚刚将一个解决方案从MVC3升级到MVC5，并开始从我的Unit项目中测试同样的异常。检查所有参考以查找旧文件，最后发现我需要在我的单元测试项目中为Mvc做一些bindingRedirects。就我而言，它有助于重置WinForms工具箱。在设计器中打开表单时出现异常；但是，编译和运行代码是可能的，并且代码的行为符合预期。异常发生在本地UserControl上，它在我引用的库之一中实现了一个接口。更新此库后发生错误。此UserControl列在WinForms工具箱中。可能VisualStudio正在保留对库的过时版本的引用，或者在某处缓存了过时的版本。以下是我从这种情况中恢复过来的方法：右键单击WinForms工具箱，然后从上下文菜单中单击“重置工具箱”。（这会从工具箱中删除自定义项）。就我而言，工具箱项目已恢复为默认状态；但是，工具箱中缺少指针箭头。关闭视觉工作室。在我的例子中，VisualStudio因违规异常而终止并中止。重新启动VisualStudio。现在一切都很好。FWIW，我在将配置文件重定向到引用程序集的不存在版本时得到了这个。融合日志赢了！我收到此错误是因为我在框架版本4.5的程序集“C”中有一个类，它在框架版本4.5.1的程序集“A”中实现了一个接口，并且作为程序集的基类“B”'也在框架的4.5.1版中。系统在尝试加载程序集“B”时抛出异常。此外，我在所有三个程序集上安装了一些针对.net4.5.1的nuget包。出于某种原因，nuget引用正在成功构建，即使它没有出现在程序集“B”中。事实证明，真正的问题是程序集引用了包含接口的不同版本的nuget包，并且接口签名在不同版本之间发生了变化。就我而言，我之前在存储库外部的同级文件夹中引用了一个mylib项目——我们称它为v1.0。|--我的仓库||--consoleApp||--子模块||--mylib(submoduledv2.0)|--mylib(stalev1.0)后来我把它弄好了，通过gitsubmodules使用它——让我们调用v2.0。但是，一个项目consoleApp没有正确更新。它仍然引用我的git项目之外的旧v1.0项目。令人困惑的是，VisualStudioIDE将路径显示为v2.0项目，即使*.csproj明显错误并指向v1.0！F12检查接口和类也到v2.0版本。编译器放到bin文件夹下的程序集是v1.0版本的，很头疼。IDE欺骗了我，这让我更难发现这个错误。解决方案：从ConsoleApp中删除项目引用并重新读取它。一般提示：从头开始重新编译所有程序集（如果可能的话，当然不是针对nuget包）并检查bindebug文件夹中的日期时间戳。任何旧的日期装配都是你的问题。我遇到了几乎同样的问题。是什么导致了这个错误。我交叉检查并实施了所有方法。谷歌搜索我得到了这个链接。根据@PaulMcLink评论，这两个步骤解决了问题。重新启动VisualStudioClean，Build（重建），错误消失。重新启动VS插件谢谢Paul:)希望这对遇到此错误的人有所帮助:)我在运行单元测试时遇到了这个问题。该应用程序运行良好，没有错误。我的问题的原因是我关闭了测试项目的构建。为我的测试项目重新启用构建解决了这些问题。我在VisualStudioPro2008中看到了这一点，当时两个项目构建了具有相同名称的程序集，一个是libSDF.dll类，另一个使用程序集名称sdf.exe引用了lib。当我更改引用程序集的名称时，异常消失这是我对这个错误的看法。添加了一个外部方法，但粘贴有问题。DllImportAttribute放在注释掉的行上。///（为简洁起见已删除lol）[DllImport("user32.dll")][返回：MarshalAs(UnmanagedType.Bool)]publicstaticexternboolIsWindowVisible(IntPtrhWnd);确保该属性实际上包含在源中解决了这个问题。我在WCF服务中得到了这个，因为选择了x86构建类型，导致bisn位于binx86而不是bin下。选择任何CPU都会导致重新编译的DLL转到正确的位置（我不会首先详细说明这是如何发生的）。这只是意味着实施项目在我的案例中已经过时了。包含接口的DLL已重建，但实现dll已过时。我也有同样的问题。我发现我的程序集是由主程序加载的，并且一些引用将“CopyLocal”设置为true。这些引用的本地副本在同一文件夹中查找其他引用，但这些引用不存在，因为其他引用的“CopyLocal”设置为false。删除“意外”复制的引用后，错误消失了，因为主程序已设置为找到引用的正确位置。显然，引用的本地副本打乱了调用顺序，因为使用了这些本地副本而不是主程序中存在的原始副本。回车消息是由于缺少加载所需组件的链接而导致的错误。就我而言，我试图使用TypeBuilder创建一个类型。TypeBuilder.CreateType抛出此异常。我最终意识到，在为有助于实现接口的方法调用TypeBuilder.DefineMethod时，我需要将MethodAttributes.Virtual添加到属性中。这是因为没有此标志，该方法不会实现接口，而是实现具有相同签名的新方法（即使未指定MethodAttributes.NewSlot）。作为附录：如果您更新用??于生成假程序集的nuget包，也会发生这种情况。假设您安装了一个nuget包的V1.0并创建了一个假组件“fakeLibrary.1.0.0.0.Fakes”。接下来，您将更新到最新版本的nuget包，例如v1.1，它向接口添加了一个新方法。Fakes库仍在寻找该库的v1.0。只需移除假组件并重新生成即可。如果那是问题所在，这可能会解决它。最近的Windows更新后出现此错误。我有一个服务类设置为从接口继承。该接口包含一个返回ValueTuple的签名，这是C#中的一项相当新的功能。我只能猜测WindowsUpdate安装了一个新的，但甚至明确引用了它，更新了绑定重定向等......最终结果只是将方法的签名更改为“标准”，我想你可以这么说。以上是C#学习教程：TypeLoadException的意思是“未实现”，但是已经实现了分享的所有内容。如果对大家有用，需要进一步了解C#学习教程，希望大家多多关注。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
