A better way to handle DLL Hell?

TL;DR — how do I ensure that the newer versions of dlls that ship with my plugin get loaded instead of older ones shipping with other plugins?

I’m developing a plug-in that depends on some third-party packages, like AWSSDK and Newtonsoft.JSON (Isn’t it always?). Because the order in which Grasshopper loads plugins and DLLs cannot be controlled by a third party developer, I have no control over whether GH loads an old version of Newtonsoft, or the newer version I need.

These are not direct dependencies, but secondary dependencies of another library I need, which specifies (and relies on features of) newer versions of these dlls. This means I cannot just edit my plugin to stop relying on the newer features, and tolerate an older version of these libraries.

So far I’m resorting to doing a little reflection check in GH_AssemblyPriority.PriorityLoad() which tests whether the newer methods I need are present in the loaded versions of each assembly in the appdomain, and warn the user to delete older versions of the DLLs in the rhino command line. This doesn’t feel particularly sustainable or discoverable.

Is there a better way to handle this? I’ve been pointed in the direction of some DLL-merging solutions but so far haven’t had much success. I thought of introducing a custom AssemblyResolve handler, but by the time my plugin is getting loaded, it’s already too late. @DavidRutten or anybody — thoughts on this?

1 Like

But that’s happening if a different library has a component class that references those packages (GH instantiates the class in order to populate its menus, I think?), so by the time my GH_AssemblyPriority.PriorityLoad() runs, the Dlls are definitely already loaded into the AppDomain.

yes you’re right :cold_sweat:

Don’t know if this content helps:

by using bindingRedirect directive.

Necroposting, but recently spent a better part of a day debugging a DLL conflict between two GH plugins.

What eventaully “fixed” it, altough I wouldn’t still consider it a perfect solution was making sure the Memory load *.GHA assemblies using COFF byte arrays option in GrasshopperDeveloperSettings was turned off. Might be worth trying first before you dive deeper into overriding AssemblyResolve etc.

Screenshot 2022-12-14 172426

Further potentially useful reading: