Strong name breaks dependency resolution

[Shane32]

I have an open source library built on iTextSharp.LGPLv2.Core 3.4.18, and was using it in an application that referenced 3.4.21. When upgrading the application to use 3.4.22, library methods that accept classes defined within iTextSharp now display an error that there is no reference to iTextSharp 3.4.18 -- even though I can use iTextSharp classes within the application without an issue.

So now it seems that users cannot upgrade to 3.4.22 if they are using libraries that depend on iTextSharp 3.4.21 or prior.

Is this your understanding? Is there a particular reason that strong assembly signing was added? Do you know of an easy workaround? Obviously the library can be updated to reference 3.4.22, but bumping a revision number in a version implies that it is fully backwards compatible, which this is not. Would it be prudent to mark 3.4.22 on NuGet as deprecated/hidden and re-release the library as 4.0.0 ? Just an idea. And then I would need to release a new major version of my library.

On a side note, while the library targets .NET Standard 2.0, the application in question targets .NET 8. I thought that .NET 8 disregarded strong assembly signing, but apparently this does not appear to be entirely the case.