System.TypeLoadException

[goswinr]

When loading in Revit 2023 there is a System.TypeLoadException: Could not load type 'System.Diagnostics.ActivitySource' from assembly 'System.Diagnostics.DiagnosticSource, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.

a binding redirect in Revti.exe.config might be needed. See https://forums.autodesk.com/t5/revit-api-forum/proper-way-to-handle-app-config-bindingredirects-in-revit-add-in/td-p/5692149

06-25-2015 06:31 AM Some more news on this, both good and bad, or maybe both:

1. First, The Revit development team is loath to provide any formal recommendation. There are several possible approaches and we cannot be responsible for any use of a wrong one. We have (and still do) used assembly resolvers ourselves. That does not mean it is a universal solution. It may cause complications, for the event may possibly be raised for more assemblies then those the user actually cares about. Therefore, we can only say that assembly resolvers provide one possible way worth exploring.

2. Secondly, using an assemblyBinding redirect is a bit, well, dictatorial. It’s telling every part of Revit and its associated modules that they must use a certain version of a specified assembly. This doesn’t always have positive results.

3. Third, we have seen issues with third-party developers editing Revit.exe.config. When we ship subsequent official patches, upgrades, etc. to the field, the installer software will not overwrite/upgrade Revit.exe.config if it has been dirtied since its original installation; in such cases, the upgrade fails (and---what is worse---fails silently). When customer support eventually deduces the problem and provides the user with a new Revit.exe.config for manual overwriting, then whatever add-ons/add-ins/third-party apps made the original edits will be broken, so for the user it’s yet another call to somebody’s customer support to get that worked out.

With all this in mind, we would really like to help third-party developers find a solution that does not include editing Revit.exe.config. Unfortunately, we don’t have all the answers at this point, but we plan to pursue this further because of the reasons stated above, so please keep us up to date with your requirements, research and results.

Thank you! Cheers, Jeremy

10-17-2023 07:36 AM No new developments, no, but similar issues such as yours keep popping up and the various solutions discussed above and in the links still apply unchanged. Assembly resolver, IPC to disentangle etc. I cannot tell which is the best way to go for you.

[goswinr]

Using ILMerge might be a better solution: https://fsharp.github.io/fsharp-compiler-docs/fsharp-core-notes.html#FSharp-Core-and-static-linking https://forums.autodesk.com/t5/revit-api-forum/reference-external-dll-conflicts-ilmerge-fody-etc/td-p/9624575

[cwaluga] ‎07-09-2020 01:01 PM I use ILMerge to bundle external [cwaluga] ‎07-09-2020 01:01 PM I use ILMerge to bundle external libraries including their references into one versioned DLL each, for instance ThirdPartyStuff_1.76.dll contains version 1.76 of „third party stuff“ including possible dependencies. This can be used without problems alongside other versions different plugins may use, at least unless somebody coincidentally names another version or DLL in the same way (which is highly unlikely).

side note: it is unbelievable that in 2020, after years of progress made in the .Net environment, dll hell is still an issue. libraries including their references into one versioned DLL each, for instance ThirdPartyStuff_1.76.dll contains version 1.76 of „third party stuff“ including possible dependencies. This can be used without problems alongside other versions different plugins may use, at least unless somebody coincidentally names another version or DLL in the same way (which is highly unlikely).

side note: it is unbelievable that in 2020, after years of progress made in the .Net environment, dll hell is still an issue.

[goswinr]

or https://github.com/Fody/Costura