Forwarding binding is added to each app.config

Question

I have 20 projects in a solution file. 1 of the projects is a standard library project, in which all the links to the projects.

About a year ago, we added a new nuget package, let's call it Package A Version 5.0.0.0. He had a lot of files that he would rewrite at compile time, but in the end we got it. We added a package to our standard library project (one that contains 19 links).

I am new to Nuget (maybe I did something wrong), so I made a new package to serve as an assistant for Package A I configured everything so that the assistant depended on Package A version 3.0.0 to 5.0.0.0 (which means it works for others who have a lower version than ours). Lets call this new package Package A helper

I install Package A helper and everything works as it should. I'm going to make a stretch request, and every single app.config in our solution now has

 <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Package.A" publicKeyToken="8FC3CCAD86" culture="neutral"/> <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0"/> </dependentAssembly> </assemblyBinding> </runtime> 

It will compile without it, but the visual studio complains and gives a warning. What gives? My manager will not let me merge my code now because it adds too much noise to app.config and depends too much on package A.

why should adding a package A dependent nuget then have to have this new bindRedirect when the main dependency was already done before we installed Package A helper ?

And why does it say 0.0.0.0-5.0.0.0 when I specified 3.0.0.0-5.0.0.0 in the nuget package and package.config

Update:

When I create a Package A helper with links to Package A version 5.0.0.0, then all bindRedirects will not be automatically populated in each app.config, but warnings are generated instead. I originally built it with 3.0.0.0 because I decided it was best to build it with the lowest dependency. The problem still exists, because the visual studio still warns and suggests creating a registry binding.

 No way to resolve conflict between "Package A, Version=5.0.0.0, Culture=neutral, PublicKeyToken=83hfhsd33" and "Package A, Version=3.0.0.0, Culture=neutral, PublicKeyToken=83hfhsd33". Choosing "Package A, Version=5.0.0.0, Culture=neutral, PublicKeyToken=83hfhsd33" arbitrarily. Consider app.config remapping of assembly "Package A, Culture=neutral, PublicKeyToken=83hfhsd33" from Version "3.0.0.0" [] to Version "5.0.0.0" [path to Package A dll] to solve conflict and get rid of warning. 

Is the solution just to change my nuget package dependency from 3.0.0.0 to 5.0.0.0 and just allow 5.0.0.0 and get rid of my allowedVersions="[3,6)" in me package.config? I do not want to reduce the usefulness and backward compatibility of my nuget package, but at the same time I do not want any warnings or bindingRedirects needed for my main solution.

Update 2: so setting Copy Local in the reference properties to False really solved my problems, but I don’t understand why.

Answer 1

I originally built it with 3.0.0.0 because I decided it was better ...

This is where the problem started. Now your decision depends on two different versions of A.dll, one of them will overwrite the other. Which version of A.dll ends up being randomly copied to bin \ Debug. Whatever project was built last.

It cannot come to the best; the decision is doomed to failure. If there is either code in A-helper.dll, it will fail when version 5.0.0.0 finishes copying. Or will it be code in any other project using A.dll, it will fail when copying version 3.0.0.0. The end result is that the solution will always fail.

So you see that the build system is doing something with this. He notices a discrepancy and chooses one of the versions for victory. He chooses 5.0.0.0, that was the right choice. And it also modifies app.config by adding bindingRedirect, so the code that requests version 3.0.0.0 to download will really get 5.0.0.0. This might work if you made version 5 compatible with version 3. Or not, two increments in the main version number usually cause problems. You will know when you will test.

So setting Copy Local in the reference properties to False actually solved my problems

This did not solve the problem, you simply did not allow the build system to suggest that it should solve this problem for you. Since you no longer needed to copy the DLL, it is assumed that you install assemblies in the GAC so that both versions can coexist. Perhaps you did this, it is not common, and it is generally very unreasonable to do this on a dev machine. It is very unlikely that your boss and team members will like this solution, given the additional installation step.

---

So, you can do two main things:

• Let the build system handle this. Be that as it may, she solved the problem correctly, and your solution will work. If version 5 is sufficiently compatible with version 3, then the code in A-helper.dll will execute correctly. If the boss doesn't like this, you will of course have to scratch it and do:

• Change the link in the A-helper project to version 5.0.0.0. Now there is no longer any incompatibility, the only and only A.dll is good for all the code. Given your requirement, this is the only solution your boss will love.