1

I create primarily programs that are addins to a different parent software; other people and companies make addins for the parent software as well. This becomes a problem when two companies use different versions of the same third party library, they are loaded into the same AppDomain because the parent software is the one loading them.

Lets use Newtonssoft.Json.dll as it's pretty common. If I use 12.0.1 and some other company uses 11.0.2 then there is a conflict. If their addin is loaded first then I get version 11.0.2 as it's already loaded, which can cause my app to collapse. If mine is loaded first, it's vice versa; theirs will get 12.0.1 and likely collapse. Both work without issue on their own, but one or the other creates a fatal error if they are both installed.

Is there a way to encapsulate these so that they load independently? I recently discovered Costura.Fody and thought maybe that was the answer. However, it still loads the assembly with the same name even though it's loading from embedded instead of disk. I also noticed that internally it changes the name to 'Costura.Newtonsoft.Json' but when I tried it in debug, it was still loaded as 'Newtonsoft.Json'. I'm wondering if there is any way to somehow change the name or identity that .NET loads the dependencies as so that it sees it as different and can be isolated from other addins in the same app domain. Something like making it load as ABC.Newtonsoft.Json.dll and then the other company could load as DEF.Newtonsoft.Json.dll or something.

Anyway, looking for some good way to deal with this on a permanent basis... Any help is greatly appreciated.

sfaust
  • 2,089
  • 28
  • 54
  • 2
    https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/redirect-assembly-versions – Selvin Jan 14 '19 at 21:49
  • Ok I read through that, however I don't think that's the answer... That would be at the app level instead of my dll level; I could technically modify the app.config for the parent app, but that's probably not advised. Also, wouldn't it force my version and just hijack the other programs? – sfaust Jan 14 '19 at 22:03
  • AFAIK with Newtonssoft.Json.dll (and those dll versions) there should be no problem. – Selvin Jan 15 '19 at 07:45
  • I was just using that as an example of a library that may be used by both. There could be several, some strong named some not... Telerik UI for WPF libraries are ones I know I have seen conflicts with. – sfaust Jan 15 '19 at 16:18

1 Answers1

2

We had the same problem with BouncyCastle been referenced with 2 main libraries that we use in our system. One of the library was the itextsharp, The remedy was, we add extern alias where we import lib. Prior adding `extern' we set the Aliases property as in the picture attached.

enter image description here

Then we referenced the BouncyCastle as below using itextsharp.Org.BouncyCastle.Security;

Hope this helps

RSF
  • 510
  • 6
  • 18
  • Thanks, interesting reading, I didn't know that existed :). However, your situation is a little different. You control the "parent" app and these are two known referenced libraries that you can differentiate at design time. In mine, I am adding into a parent program that I don't control. Using just my code and the 'vanilla' parent my app works just fine. When you add other apps into the parent that may or may be referencing unknown versions of shared libraries it may break, but it's not known at design time what may be loaded... – sfaust Jan 14 '19 at 22:18