Set Release version in Assembly version to avoid GAC conflicts

[JustinSchneiderPBI]

Set the Release version in the Assembly version to avoid GAC conflict
This is an attempt to fix #2887

Tests should be added.

[JamesNK]

Locking the assembly version to the major version is an explicit choice to avoid binding redirects having to be updated with every release. I know the downside is each version can't be GACed individually.

The current versioning scheme won't change.

[JustinSchneiderPBI]

Locking the assembly version to the major version is an explicit choice to avoid binding redirects having to be updated with every release. I know the downside is each version can't be GACed individually.

The current versioning scheme won't change.

Thanks for the reply, James! I feel like I'm either missing the benefit or you're expecting it's more significant than it is. Updating the binding redirect is trivial, in my mind. Those should be automatically managed by the build nowadays anyway, right? But when someone GACs a different version of Newtonsoft, the product completely breaks. For me, as a developer consumer of Newtonsoft, I'd much rather have to change 1-1000 lines of (repetetive) code (if the build doesn't handle it for me), than have customers completely blocked pinging us. When it does happen, we have to do a deep investigation to figure out that a different version of newtonsoft is GAC'd. Most of our new developers would have no clue where to start with this. I think we had to get a customer to install the fusion logger on their machine the first time this happened. Can you elaborate what the value of the benefit is that you're trying to achieve with less binding redirect updates? Or maybe there's a simple workaround I'm missing, since it feels like I'm missing something key here. Thanks for your time.

[JamesNK]

Most people don't use the GAC and they don't strong name their apps. Forcing binding redirect changes on all those people each time the produce changes is painful. The current scheme is to balance people who want the option to use Newtonsoft.Json in a strong named app without too much pain for people who don't.

Even if Newtonsoft.Json did change the assembly version with each release, there are multiple builds with that assembly version. Your app might need Newtonsoft.Json 13.0.3 that is built for .NET 4.5, but someone else GACed Newtonsoft.Json 13.0.3 that is built for .NET 2.0. It's still broken.

[JustinSchneiderPBI]

Thanks, that clarifies a lot. I missed that the strong name signing difference is the reason it crashes, not a build version incompatibility. We'll keep thinking about this then, and maybe add something to detect the issue for customers into our installer. Hopefully we can find something more elegant. Otherwise, we'll look forward to migrating to .Net without strong-name-signing at some point.