我们的测试机器上有个很奇怪的bug。错误是:
系统。来自程序集“activeviewer(…)”的类型“DummyItem”中的方法“SetShort”没有实现。
我就是不明白为什么。SetShort在DummyItem类中,我甚至重新编译了一个版本,写入事件日志,只是为了确保它不是部署/版本控制问题。奇怪的是,调用代码甚至不调用SetShort方法。
我们的测试机器上有个很奇怪的bug。错误是:
系统。来自程序集“activeviewer(…)”的类型“DummyItem”中的方法“SetShort”没有实现。
我就是不明白为什么。SetShort在DummyItem类中,我甚至重新编译了一个版本,写入事件日志,只是为了确保它不是部署/版本控制问题。奇怪的是,调用代码甚至不调用SetShort方法。
当前回答
作为补充:如果更新用于生成假程序集的nuget包,也会发生这种情况。假设您安装了一个nuget包的V1.0版本,并创建了一个假程序集“fakeLibrary.1.0.0.0.Fakes”。接下来,更新到nuget包的最新版本,比如v1.1,它向接口添加了一个新方法。Fakes库仍在寻找该库的1.0版本。只需移除假组装和再生它。如果这是问题所在,这可能会解决它。
其他回答
我在使用Autofac和大量动态程序集加载时遇到了这个错误。
在执行Autofac解析操作时,运行库将无法加载其中一个程序集。错误消息抱怨程序集'ImplementationAssembly'中的'MyType'类型的方法'MyMethod'没有实现。在Windows Server 2012 R2虚拟机上运行时出现问题,但在Windows 10或Windows Server 2016虚拟机上没有出现问题。
ImplementationAssembly引用System.Collections.Immutable 1.1.37,并包含IMyInterface<T1,T2>接口的实现,该接口在单独的definentationassembly中定义。defintionassembly引用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。不可变,这意味着运行时不考虑实现类与接口定义匹配。
添加以下绑定重定向到我的应用程序配置文件修复了这个问题:
<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>
以下是我对这个错误的看法。
添加了一个extern方法,但我的粘贴是错误的。DllImportAttribute被放到一个注释出来的行。
/// <returns>(removed for brevity lol)</returns>[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool IsWindowVisible(IntPtr hWnd);
确保属性实际包含在源代码中解决了这个问题。
另一种可能是在依赖关系中混合发布和调试构建。例如,程序集A依赖于程序集B, A是在调试模式下构建的,而GAC中的B副本是在发布模式下构建的,反之亦然。
还有另一种方法:
class GenericFoo<T> {}
class ConcreteFoo : GenericFoo<ClassFromAnotherAssembly> {}
程序集中的代码,不引用ClassFromAnotherAssembly的程序集。
var foo = new ConcreteFoo(); //kaboom
当ClassFromAnotherAssembly是ValueTuple时,这发生在我身上。
我也发现了同样的信息,以下是我们的发现: 我们在项目中使用第三方dll。在这些dll的新版本发布后,我们将项目更改为指向新的dll集,并成功编译。
当我试图在运行时实例化它们的一个接口类时,抛出了异常。 我们确保所有其他参考资料都是最新的,但仍然没有运气。 我们需要一段时间来发现(使用对象浏览器)错误消息中方法的返回类型是来自一个新的、未引用的程序集的全新类型。
我们向程序集添加了引用,错误就消失了。
错误消息相当误导人,但或多或少指向了正确的方向(正确的方法,错误的消息)。 即使我们没有使用有问题的方法,还是出现了异常。 这就引出了一个问题:如果在任何情况下抛出了这个异常,为什么编译器没有拾取它?