When a .net library is signed, a reference to this library is tied to that specfic build. This means that if nuget package A is built against version 1.0 of a signed assembly, and states that it needs AT LEAST version 1.0, and a nuget package B is built against version 2.0 of the same assembly, and states that it needs at least version 2.0, nuget will include version 2.0 of the signed assembly in the project. However, when a method of nuget package A that uses the signed dll is called, a runtime error will occur because it cannot find version 1.0 of the signed dll.
The behavior is differently when the dll is not signed. In that case, the nuget package code simply redirects the binding to version 2 of the (unsigned) library, and no errors occur.
We have a similar situation in our project. Our main project is build against a specific version of aspose.cells. We have a plugin that is added to the project at some customers. This plugin might be built against a different version of aspose cells, because it is specific to a version of our product, so the aspose.cells version used in our main product may change over time. However, this plugin now no longer runs, because it requires a different version of aspose.cells than the one in our main product.
Again, this conflict does not occur when the dll’s are not signed.