Scope of embedded references

[SBarnes]

I think I already know the answer to this question which going to be no, but I am going to ask is there a way to limit the scope of an embedded reference to the plugin only as I have just had an instance with a customer where 2 plugins use the same 3rd party library but were relying on two different versions and it has caused a problem/conflict.

I would assume that the embedded library that will load will be based upon the plugin load order such as execution order and name etc.

[Mike.Sheen]

I think I already know the answer to this question which going to be no, but I am going to ask is there a way to limit the scope of an embedded reference to the plugin only as I have just had an instance with a customer where 2 plugins use the same 3rd party library but were relying on two different versions and it has caused a problem/conflict.

I would assume that the embedded library that will load will be based upon the plugin load order such as execution order and name etc.

This is a .NET Framework behaviour - once an assembly is loaded into the app domain, it cannot be unloaded and remains for the life of the app domain. If the two different versions were strongly named with different strong name keys, then I think you should be able to load both versions - but I suspect like most authors of assemblies, they used the same strong name key for all versions.

If you were to change one of your problematic plugins to not use an embedded reference, but instead loaded the assembly from file system manually (like we do with some plugins - store it in the documents tab and extract it in the plugin code itself) you'll probably find that you encounter a problem, if the other version is already loaded.

I would have thought it would not take much effort to make the two plugins target the same version of the 3rd party assembly - most likely just a case of removing the embedded reference from one of the plugins and adding back the embedded reference, but the same as the other plugin.

[SBarnes]

I would have thought it would not take much effort to make the two plugins target the same version of the 3rd party assembly - most likely just a case of removing the embedded reference from one of the plugins and adding back the embedded reference, but the same as the other plugin.

Pretty much the answer of what I did just took a while to figure out why the strange behaviour was happening in the first place.

Thanks for the response.