我们的测试机器上有个很奇怪的bug。错误是:
系统。来自程序集“activeviewer(…)”的类型“DummyItem”中的方法“SetShort”没有实现。
我就是不明白为什么。SetShort在DummyItem类中,我甚至重新编译了一个版本,写入事件日志,只是为了确保它不是部署/版本控制问题。奇怪的是,调用代码甚至不调用SetShort方法。
我们的测试机器上有个很奇怪的bug。错误是:
系统。来自程序集“activeviewer(…)”的类型“DummyItem”中的方法“SetShort”没有实现。
我就是不明白为什么。SetShort在DummyItem类中,我甚至重新编译了一个版本,写入事件日志,只是为了确保它不是部署/版本控制问题。奇怪的是,调用代码甚至不调用SetShort方法。
当前回答
这仅仅意味着实现项目在我的案例中已经过时了。重新构建了包含接口的DLL,但实现DLL陈旧。
其他回答
我在WCF服务中得到了这个,因为选择了x86构建类型,导致箱子在bin\x86下而不是bin下。选择Any CPU会导致重新编译的dll到达正确的位置(我不会详细说明这是如何发生的)。
在最近的一次windows更新后,我收到了这个错误。我设置了一个从接口继承的服务类。该接口包含一个返回ValueTuple的签名,这是c#中的一个相当新的特性。
我所能猜到的是,windows更新安装了一个新的,但即使显式引用它,更新绑定重定向,等等…最终的结果只是将方法的签名更改为“标准”的东西。
如果使用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;
}
在我的例子中,我以前在repo之外的兄弟文件夹中引用了一个mylib项目——让我们称之为v1.0。
|-- myrepo
| |-- consoleApp
| |-- submodules
| |-- mylib (submoduled v2.0)
|-- mylib (stale v1.0)
后来我做了正确的,并通过一个git子模块使用它-让我们称之为v2.0。 然而,一个项目consoleApp没有正确更新。它仍然在我的git项目之外引用旧的v1.0项目。
令人困惑的是,尽管*。csproj显然是错误的,并且指向v1.0, Visual Studio IDE将路径显示为v2.0项目! F12来检查接口和类也去了v2.0版本。
编译器放在bin文件夹中的程序集是v1.0版本,因此令人头疼。
IDE对我撒谎的事实让我很难意识到这个错误。
解决方案:从ConsoleApp中删除项目引用并读取它们。
一般提示:从头重新编译所有程序集(如果可能的话,当然不能用于nuget包),并检查bin\debug文件夹中的日期时间戳。任何过时的程序集都是你的问题。
还有另一种方法:
class GenericFoo<T> {}
class ConcreteFoo : GenericFoo<ClassFromAnotherAssembly> {}
程序集中的代码,不引用ClassFromAnotherAssembly的程序集。
var foo = new ConcreteFoo(); //kaboom
当ClassFromAnotherAssembly是ValueTuple时,这发生在我身上。