I decided against trying to replace the config time binding redirects with the runtime assembly resolution. The reasons – I do not know how to ensure it reliably given:
- Different types of runnable projects – console apps, Asp.Net applications, WCF services, unit test projects. And we have them all.
- The code may spawn different App Domains and each one has to have this assembly resolution logic. I do not think it is possible at all in general.
Instead I decided to leverage the following aspects of our setup:
- We already enforce consistent versioning of all the NuGet packages we reference. Migrating to PackageReference has drastically reduced the amount of packages we have control over – hence the numerous problems. But those we directly reference are in order.
- We now have project.assets.json files which present the entire picture when it comes to NuGet package and project references. We cannot change the transitive dependencies (like we could with packages.config), but we can be aware of all of them.
This makes it possible to write a tool that could read project.assets.json for the given project (and recursively for all the other projects it depends on) and based on them do two things:
- Identify all the NuGet package dependencies which are mentioned with different versions. E.g. if NuGet package X depends on NuGet package Y v1, but NuGet package Z depends on Y v2, then Y is problematic. And we can recognize this condition and determine the file path of the highest version – v2.
- Update the binding redirects automatically.
- After the build copy the files identified in the first step to the published directory.
This way the binaries in the bin folder would not depend on the build order of the projects in the solution and we would have a deterministic process to maintain the binding redirects.
This is a work in progress, but it looks promising – https://github.com/MarkKharitonov/GenerateDotNetBindingRedirects
CLICK HERE to find out more related problems solutions.