Rock could use better support for handling 3rd party DLL references. There are currently two problems we face as plugin developers.

1. When the plugin contents are extracted, they are just written to disk. This means an older version of a DLL might end up replacing a newer version. Example: XYZ.dll is used by both plugins A and B. Plugin A uses version 2.4.0 while plugin B uses version 2.0.0. If plugin A is installed first then version 2.4.0 gets installed. When plugin B then gets installed, XYZ.dll is replaced with version 2.0.0. Most likely causing plugin A to stop working.

2. Strong named assemblies must currently be exact matches. In the case of #1 above, there is only a chance that plugin A will stop working. If it isn't using any new features introduced since version 2.0.0 then it will probably work fine. But if the referenced assembly is strong named then it won't matter. Whichever plugin is installed first will cease to work. Even if the original XYZ.dll version is 2.0.0 and then upgraded to 2.4.0 the initial plugin will stop working because it is looking explicitly for 2.0.0.

I believe two changes should be introduced to Rock's plugin installation system. First is DLL version checking. If a .DLL is being written to disk and an existing DLL is already there, make sure latest version is the one that is kept. Second, We should make use of the AppDomain.AssemblyResolve event to handle loading a newer version of the requested signed library.

I have tested the AssemblyResolve event and it seems to fix the second issue with only a few lines of code.

There is also the possibility of saving BOTH strong-named DLL versions and using the AssemblyResolve event to load the correct version from disk. In theory, this would allow both versions to be loaded at the same time. As long as Plugin A doesn't get data from XYZ and then pass it along to plugin B there shouldn't be any issue doing this. The only potential issue might be if Plugin's are trying to directly access the DLL in the bin folder.

I can't directly fund this idea with money, but I can fund it with a pull request. However I would want to talk through some of the specifics first to make sure I'm on the same page as the core team. More and more NuGet packages are distributing strong named DLLs which is making my life as a plugin author difficult as I have to avoid using those libraries. Worse, they don't always say they are strong named unless I check with a command line tool.