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?
