Missing Method Exception in Plugin's Project-Referenced dll; Revit 2019, 2020, 2022

[Anonymous]

Hi Autodesk community,

Long time lurker, first time poster here with EvolveLAB hoping for some insight on a weird Plugin-loading issue. I've been banging my head on this bug for near 4 weeks now, so any insight will be greatly appreciated! 

Background:
     This bug is in the Revit Plugin portion of our new, in-development v2.0 of our Helix product which allows SketchUp and Revit to synchronize BIM data (in real time now!). This version is a complete rebuild using a different architecture from the first version, leveraging modern web technologies to hack a 'Google docs'-like realtime collaboration experience into Revit, Sketchup, and potentially any other similar app with plugin support.

Context:

• Used to work in an earlier build, but no longer works
• This part of the codebase has not changed since it last worked
• First known change was installing Revit 2019 on test computer
  • Was originally working on just 2020
  • Have since tried uninstalling all versions except 2022; no change
• Have also tried compiling to libraries to .NET Framework 4.8
  • Was originally compiling libraries to .NET Standard 2.0 (to facilitate reuse in .NET Core portions of the codebase)
  • Main Revit Plugin POE dll was and still is compiled to .NET Framework 4.8
• Looks like it may be an issue with the JIT compiler or Linker?
• Problem might be Revit update based / perhaps not with the code itself?

Problem:

• When loading the Revit Plugin, it seems to load fine; until we call a method which contains a call to our in-house dependency injection library (EvolveLAB.Common.DependencyInjection.dll).
• The error thrown is “System.MissingMethodException” (Revit 2020)
• 
• This exception is thrown before the compiler is able to hit a breakpoint which is in the same method, but before the line which throws the exception
  • The Visual Studio debugger does properly attach to Revit before the Plugin tries to load
  • The Visual Studio debugger does properly load debug metadata for the Plugin's libraries before this exception gets thrown
  • This is what makes me think the issue occurs during Linking or JIT Compilation

Tried:

• Deleting all dlls on machine to make sure that the app does not somehow reference an old version from elsewhere.
• Decompiled the dll to see if the missing method is missing, and the method in the decompiled code is there.
  • Decompiled using JetBrains' dotPeek (https://www.jetbrains.com/decompiler/)
• Tried building the addin again from scratch to see where exactly this problem is introduced
• Error we get in the rebuild process (Revit 2022):
• 
• While decidedly different, I have a nagging suspicion that both issue have similar roots (dunno how/why though)
• Here are some the references that have given us other issues in the past:
• Microsoft.Extensions.DependecyInjections
• Microsoft.Extensions.DependecyInjections.Abstractions
• System.Threading.Tasks
• System.Threading.Tasks.Extensions
• Microsoft.Bcl.AsyncInterfaces
• QUESTION:
• Are there known issues of conflicts with a third party app loading the references above?
• If not, does anyone have experience getting Revit to find a method which it claims doesn't exist, but that dotPeek shows as there?

I'm currently looking into the GAC to see if maybe Windows has cached an old version of our DependencyInjection without my noticing, but that's quite a long shot...

Thanks in advance for help with this!

[Sean_Page]

Are you trying to use binding redirects? I have been struggling for several weeks with "dll hell" related to using a PostgreSQL extension and also struggled with most of the references you mention above.

Also, have you checked to see if any other addins are loading the same dll? When I search for that I find it in a couple different locations.

C:\Program Files\Autodesk\Revit 2022

[Anonymous]

I have Visual Studio Autogenerating binding redirects currently. I remember there was a point where the Plugin was working without the binding redirects, but I honestly don't remember when turning those on fall into the bug-fix-find timeline

I've made sure that there're no other addins being loaded apart from the Helix plugin, so it's unlikely that something else is loading a conflicting dll (though it is possible that Revit itself loads a conflicting dll?)

[Sean_Page · Accepted solution]

I would recommend using this logging tool to see where / how / why the references are being loaded. It will also tell you if its actually a location issue, or a version issue.

Fuslogvw.exe (Assembly Binding Log Viewer) | Microsoft Docs

[Anonymous]

That solved it! Well, Fuslogvw set the dominos in motion for figuring out the cause of our issue! Sorry for the delay replying; it took a minute to both figure out how to effectively use the tool and to follow the strand it uncovered back through the DLL spaghetti to a solution

Turns out that supposed "MethodNotFoundException" from our in-house Dependency Injection (DI) library was actually a misdiagnosed DLL version mismatch for Microsoft.Extentions.DependencyInjection (MSDI) where DI was expecting MSDI v5.0, but the plugin was providing v1.1. (Presumably, due to the version mismatch, the JIT compiler [JIT linker if that's a sperate thing?] was unable to use the MSDI ServiceProvider type. That then made set_ServiceProvider in DI unable to compile/resolve the property, thus making it appear non-existent)

After that, I spent a few days fruitlessly trying to figure out why I was getting a different version of the system-level dll than was being requested, until confusion/frustration convinced me to take a sec to update solution Nuget packages if just to not think about this bug a moment. Guess what I found sneakily installed via Nuget? Microsoft.Extentions.DependencyInjection! In multiple projects; some referencing v5.0, others v1.1 *facepalm*

In my defense, there were a good number version conflicts in MSDI's dependencies that needed untangled before just hitting the 'update' button would work (and those were probably what originally caused this issue); but yes, this did end up being just an unusually obfuscated nuget-version mismatch issue. We've got all .NET 5, Core, and Framework targets now running MSDI v5.0 quite happily

TL;DR: If you see strange linker/assembly resolution/jit compiler issues, check your nuget packages! It's an easy place to check, and can (apparently) produce very unrelated-looking exceptions in Revit

P.S. Thanks @Sean_Page for bringing Fuslogvw.exe to my attention. Not only was it critical in ultimately solving this issue, but also seems to be an incredibly powerful tool in general! Not sure how I've gone this long not knowing about it, but it's going to be a regular on my proverbial tool belt from now on!

[Sean_Page]

It's great to hear you got it all resolved!

One item to note about using Fusion logging is that you'd be wise to turn it off and on (regedit) when you aren't debugging issues because the log files (size/ quantity) can get very large very quickly.

[Anonymous]

Ooh, that makes sense. Thanks for the heads-up!