AssemblyResolve ignores strong named DLLs

Rhino Developer
,
1

Hello everyone,

I have two plugins, each needs to load a different version of the same DLL.
These DLLs are strong named and are placed in separate subfolders.
I want to subscibe to the AssemblyResolve event and load the correct DLL in each plugin.

For the first plugin everything works as expected. The event handler is called and the DLL is loaded.
For the second plugin the eventhandler is not called. I investigated the issue and found this implementation here:

https://github.com/mcneel/rhinocommon/blob/master/dotnet/resolver.cs

I see that this is outdated but maybe the implementation is still similar.
In line 64 the searchname is changed so that the version information is no longer considered:

index = searchname.IndexOf(',');
if (index > 0)
{
	searchname = searchname.Substring(0, index);
}

As the next step, in line 75, the currently loaded dlls are checked and the DLL from plugin one is returned:

// See if the assembly is already loaded.
Assembly[] assemblies = AppDomain.CurrentDomain.GetAssemblies();
for (int i = 0; i < assemblies.Length; i++)
{
	if (assemblies[i].FullName.StartsWith(searchname + ",", StringComparison.OrdinalIgnoreCase))
		return assemblies[i];
}

My event handler are not called afterwards because it seems that the event handler are only called until the first listener returns someting other than null.

Does someone have an idea what I could do? I’m not sure if there is any way to solve this issue without changing the resolve.cs (assuming that the code is still similar).

Thanks in advance
Patrick

Please note:
I know that I can use AppDomains, but it should be possible to solve this issue without them. It would create a lot of work and impact the performance.

2

Hi @mw_patrick,

The code your looking at is out-of-date and not used by Rhino 6. I’ve logged an issue so your question gets answered.

https://mcneel.myjetbrains.com/youtrack/issue/RH-56067

Thanks,

– Dale

3

The RhinoCommon assembly resolver probably won’t be changed in this respect for quite a while. I may be able to improve this, but it won’t happen until at least V7.

I would recommend forcing your specific assemblies to be loaded so there is no dependency on having the assembly resolver do the work for you. If this doesn’t work, then you could add your own assembly resolver to the AppDomain at the beginning of the delegate list.

4

Hi @stevebaer,

thanks for your reply.
Forcing the dlls to be loaded doesn’t work. They are both loaded but your resolver will always select the first one.
Changing the event oder works, but it is not the nicest solution. Depending on the execution order is never a good idea. We will have to live with this approach since it is the only option here.

For V7 it would be nice if you can fix this bug somehow.

Thanks again and best regards
Patrick