3

Setting

For our applications and utilities we try to normalize all our (open source) library dependencies over all tools to the same version; we continually build all tools to make sure everything stays working.

Problem

It happens that we must use closed source 3rd party .NET library assemblies. Some of these assemblies have their own transitive dependency on open source components. If we happen to use the same open source component, chances are that we are using a different version than the closed source dependency, and so we get a conflict.

Problem example

Just an example!

Our assembly our_abc.dll use a closed source third party assembly their_xyz.dll which references Newtonsoft.Json.dll in a different version than we do.

In this case, the json types are not used on the "API surface" between our_abc and their_xyz, which seems to be the case rather often.

Solution?

So, what we'd like to achieve is that our code just uses the open source assembly in the version it needs, and the closed source 3rd party assembly we reference should just use their version.

Ideally, this should be achieved with as little configuration file shenanigans as possible. Using the GAC seems rather clumsy for quite some deployments.

I have read about assemblyBinding, but I'm not sure whether it is the right tool for the job, as it seems we would need to manually maintain all transitive dependencies in our app.config files of all applications for this to work:

The solution in the link makes it seem look like the following. Given this dependency situation:

tool.exe -> my_abc.dll -> their_xyz.dll -> opensource.dll[v6] 
         \     ||
          \    \/ 
           \-> opensource.dll[v11]

... I understand I could prepare an app.config file for tool.exe that specifies where to look up the 2 (n) different versions of the transitive dependency.

However, from a maintainability POV, it would be better if I could bundle the information together with the their_xyz "package", so that tool.exe does not have to know about it's transitive dependencies. Is this somehow possible?

Martin Ba
  • 37,187
  • 33
  • 183
  • 337
  • You can modify app.config in prebuild action. Just plunge them all in this config file from some "lib" folder. This is gross, but pretty simple script solution. More complicated but slightly correct solution is to isolate libraries in their own folders, copy them on build and disable reference copy, then manually manage assembly loading from number of catalogs when you working with those dependencies. Though you will still be in trouble if they expose types of v6 assembly in their own..... – eocron Oct 01 '19 at 19:29
  • @eocron - thanks. What do you mean exactly by "...manage assembly loading from number of catalogs..."? – Martin Ba Oct 01 '19 at 19:57
  • I mean, manually manage AssemblyResolve or execute your dependencies in completely different AppDomain with it's own resolve path. – eocron Oct 01 '19 at 20:16
  • 1
    You can do it the same way NuGet packages are handled. First, create folders for each version of the DLL. Then, in the project, you can target the proper DLL based on your need. – billybob Oct 01 '19 at 20:40

0 Answers0