Probably not as it is relative to the version of Rhino that is running, I’ve created RH-81551 to move it to the local folder.
Yes, if the hash of RhinoCommon changes (which it does when you update), it will re-check all plugins.
1 Like
We’re hitting this issue too. It only happens when installing via the package manager in Rhino 8. When I run Compat.exe directly on all the assemblies, there’s no problem.
Microsoft.Extensions.Logging.EventLog, Version=8.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Stack overflow. at System.String.GetHashCode() at Mono.Cecil.Metadata.RowEqualityComparer.GetHashCode(Mono.Cecil.Metadata.Row
2<System.String,System.String>) at System.Collections.Generic.Dictionary2[[Mono.Cecil.Metadata.Row2[[System.__Canon, System.Private.CoreLib, Version=7.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[System.__Canon, System.Private.CoreLib, Version=7.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]], Mono.Cecil, Version=0.11.4.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e],[System.__Canon, System.Private.CoreLib, Version=7.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].FindValue(Mono.Cecil.Metadata.Row2<System.__Canon,System.__Canon>) at System.Collections.Generic.Dictionary2[[Mono.Cecil.Metadata.Row2[[System.__Canon, System.Private.CoreLib, Version=7.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[System.__Canon, System.Private.CoreLib, Version=7.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]], Mono.Cecil, Version=0.11.4.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e],[System.__Canon, System.Private.CoreLib, Version=7.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].TryGetValue(Mono.Cecil.Metadata.Row`2<System.__Canon,System.__Canon>, System.__Canon ByRef) at Mono.Cecil.TypeDefinitionCollection.GetType(System.String, System.String) at Mono.Cecil.ModuleDefinition.GetType(System.String, System.String) at Mono.Cecil.MetadataResolver.GetTypeDefinition(Mono.Cecil.ModuleDefinition, Mono.Cecil.TypeReference) at Mono.Cecil.MetadataResolver.GetType(Mono.Cecil.ModuleDefinition, Mono.Cecil.TypeReference) at Mono.Cecil.MetadataResolver.Resolve(Mono.Cecil.TypeReference) at Mono.Cecil.ModuleDefinition.Resolve(Mono.Cecil.TypeReference) at Mono.Cecil.ExportedType.Resolve() at Mono.Cecil.MetadataResolver.GetType(Mono.Cecil.ModuleDefinition, Mono.Cecil.TypeReference) at Mono.Cecil.MetadataResolver.Resolve(Mono.Cecil.TypeReference) at Mono.Cecil.ModuleDefinition.Resolve(Mono.Cecil.TypeReference) at Mono.Cecil.ExportedType.Resolve() at Mono.Cecil.MetadataResolver.GetType(Mono.Cecil.ModuleDefinition, Mono.Cecil.TypeReference) at Mono.Cecil.MetadataResolver.Resolve(Mono.Cecil.TypeReference) at Mono.Cecil.ModuleDefinition.Resolve(Mono.Cecil.TypeReference) at Mono.Cecil.ExportedType.Resolve() at Mono.Cecil.MetadataResolver.GetType(Mono.Cecil.ModuleDefinition, Mono.Cecil.TypeReference) at Mono.Cecil.MetadataResolver.Resolve(Mono.Cecil.TypeReference) at
@curtisw Is there any way that we could say in the manifest “trust me Rhino, I know this is compatible, no need to run Compat.exe” as a workaround?
Or could we get a build of Rhino with this patch in? Protect against circular type forwarders by KirillOsenkov · Pull Request #806 · jbevain/cecil
Hey @James_Duley,
There is not, sorry.
As far as I can tell, with that patch it would still fail compat checks as that simply throws an InvalidOperationException vs. getting a stack overflow. It would have to be implemented in a different way for us to ignore it on our end.
If you can send a copy of your plugin (or something that reproduces it), I can see what we may be able to do to get around that issue if possible.
RH-81476 is fixed in Rhino 8 Service Release 17 Release Candidate