我们的测试机器上有个很奇怪的bug。错误是:
系统。来自程序集“activeviewer(…)”的类型“DummyItem”中的方法“SetShort”没有实现。
我就是不明白为什么。SetShort在DummyItem类中,我甚至重新编译了一个版本,写入事件日志,只是为了确保它不是部署/版本控制问题。奇怪的是,调用代码甚至不调用SetShort方法。
我们的测试机器上有个很奇怪的bug。错误是:
系统。来自程序集“activeviewer(…)”的类型“DummyItem”中的方法“SetShort”没有实现。
我就是不明白为什么。SetShort在DummyItem类中,我甚至重新编译了一个版本,写入事件日志,只是为了确保它不是部署/版本控制问题。奇怪的是,调用代码甚至不调用SetShort方法。
当前回答
Our problem solved with updating windows! Our web application is on .Net 4.7.1 and c# 7.0. As we tested in different windowses, we understood that the problem will be solved by updating windows. Indeed, the problem was seen in windows 10 (version 1703) and also in a windows server 2012(not updated in last year). After updating both of them, the problem was solved. In fact, the asp.net minor version(the third part of the clr.dll version in C:\Windows\Microsoft.NET\Framework64\v4.0.30319 ) was changed a bit after the update.
其他回答
I have yet another esoteric solution to this error message. I upgraded my target framework from .Net 4.0 to 4.6, and my unit test project was giving me the "System.TypeLoadException...does not have an implementation" error when I tried to build. It also gave a second error message about the same supposedly non-implemented method that said "The 'BuildShadowTask' task failed unexpectedly." None of the advice here seemed to help, so I searched for "BuildShadowTask", and found a post on MSDN which led me to use a text editor to delete these lines from the unit test project's csproj file.
<ItemGroup>
<Shadow Include="Test References\MyProject.accessor" />
</ItemGroup>
在那之后,两个错误都消失了,项目建立起来了。
这类问题的另一种解释涉及托管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)。正如Ayende Rahien在Rhino Mocks邮件列表中所述,这是一个有点晦涩的modopt导致的问题。
我在WCF服务中得到了这个,因为选择了x86构建类型,导致箱子在bin\x86下而不是bin下。选择Any CPU会导致重新编译的dll到达正确的位置(我不会详细说明这是如何发生的)。
作为补充:如果更新用于生成假程序集的nuget包,也会发生这种情况。假设您安装了一个nuget包的V1.0版本,并创建了一个假程序集“fakeLibrary.1.0.0.0.Fakes”。接下来,更新到nuget包的最新版本,比如v1.1,它向接口添加了一个新方法。Fakes库仍在寻找该库的1.0版本。只需移除假组装和再生它。如果这是问题所在,这可能会解决它。
我刚刚将一个解决方案从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>