RestSharp version 106.10.1 has an internal version number of 106.0.0.0

[Vincentvanderbilt]

Expected Behavior

Version 106.10.1 should be accepted by packages that require a minimum version of RestSharp of 106.2.2.0 (for instance, Atlassian.Jira, version 11.2.0.0)

Actual Behavior

Packages that have a reference to RestSharp with a version number of 106.2.2.0 do not accept the version 106.10.1. A message is given that the version 106.0.0.0 is not high enough.

Steps to Reproduce the Problem

1. Download the RestSharp DLL version 106.10.1
2. Use ILSpy to open the dll
3. ILSpy will show the version number as 106.0.0.0

Specifications

• Version: 106.10.1
• Platform: Windows 10
• Subsystem:

StackTrace

[DukeBG]

I've run into this problem as well, while trying to use the package together with RestSharp.Newtonsoft.Json 1.5.1, which references 106.5.4.0.

This would cause build error CS1705: Assembly 'RestSharp.Serializers.Newtonsoft.Json' with identity 'RestSharp.Serializers.Newtonsoft.Json, Version=1.5.1.0, Culture=neutral, PublicKeyToken=null' uses 'RestSharp, Version=106.5.4.0, Culture=neutral, PublicKeyToken=598062e77f915f75' which has a higher version than referenced assembly 'RestSharp' with identity 'RestSharp, Version=106.0.0.0, Culture=neutral, PublicKeyToken=598062e77f915f75'

The <dependentAssembly> config entry doesn't help resolve that in any way.

It was very frustrating to not being able to use the latest versions of the pachages and I had to downgrade to RestSharp 106.6.10 which seems to have a correct internal [assembly: AssemblyVersion("106.6.10.0")]. Versions 106.8.0, 106.9.0, 106.10.0 and 106.10.1 all have this problem.

[alexeyzimarev]

RestSharp.Newtonsoft.Json is not our package.

https://restsharp.dev/usage/serialization.html#newtonsoftjson-aka-json-net

[alexeyzimarev]

Following up on the issue itself: it is not a bug.

https://github.com/adamralph/minver#version-numbers

https://docs.microsoft.com/en-ca/dotnet/standard/library-guidance/versioning#assembly-version

Strong naming combined with assembly version enables strict assembly version loading. While strong naming a library has a number of benefits, it often results in runtime exceptions that an assembly can't be found and requires binding redirects in app.config/web.config to be fixed. .NET Core assembly loading has been relaxed, and the .NET Core CLR will automatically load assemblies at runtime with a higher version.

✔️ CONSIDER only including a major version in the AssemblyVersion.

e.g. Library 1.0 and Library 1.0.1 both have an AssemblyVersion of 1.0.0.0, while Library 2.0 has AssemblyVersion of 2.0.0.0. When the assembly version changes less often, it reduces binding redirects.

[DukeBG]

RestSharp.Newtonsoft.Json is not our package.

https://restsharp.dev/usage/serialization.html#newtonsoftjson-aka-json-net

Thank you and sorry for the confusion, I guess. There is no error with the package from the page you linked. The other package is unfortunately named and has way too many nuget downloads in comparison, so it shows more prominently there. Maybe its author could take it down then.

[alexeyzimarev]

Yeah, I think so too. If you check the repo of that project, you can see it is marked as "deprecated". I already opened an issue in that repo a few weeks ago asking to resolve the package issue. But as per today, the package author did not respond to my request.

[alexeyzimarev]

@Vincentvanderbilt is it a public or private project that has a specific RestSharp assembly version referenced?

[Vincentvanderbilt]

Hi Alexey, it is a public project: Atlassian.SDK version 11.2.0. It references RestSharp, Version=106.2.2.0

[alexeyzimarev]

Their latest version uses 106.10.1 so the issue should go away as soon as they make a new release.

https://bitbucket.org/farmas/atlassian.net-sdk/src/8c6265a78e360b41cd41d96dc9b35be034c250e0/Atlassian.Jira/Atlassian.Jira.csproj#lines-27

[ghostknight63]

Well, while mentioned recommendations are good, but package 106.6.9.0 had a strong name 106.6.9.0 and there are some other packages, like https://github.com/taxjar/taxjar.net referencing by strong name.
Since @alexeyzimarev decided to cut strong name to major version only, now I can't use more recent versions of RestSharp and benefit from fixes on them till TaxJar will update.
I do believe that such a change, being in general good thing, should occur on major version increment (say with the release of 107.0.0.0) in order not to break the compatability.
Is it possible to revert that changes and get back to it on major version update, having 106.x.x have full version in their strong name? Thanks!

[alexeyzimarev]

Wait, wait. I haven't decided anything. I started using minver for semantic versioning and it applied default rules. Sorry, I wasn't aware of this. I agree it should've been the major version, now when I know what really happened.

I am fine configuring minver for 106.11 to produce the specific assembly version and get back to the new versioning scheme in 107.

[ghostknight63]

Thanks!

[Vincentvanderbilt]

Hi Alexey, that would be perfect, thank you for your fast response and effort!

[flexoft-sk]

Hi, we stumbled upon this when loading RestSharp dynamically (e.g. by Unit test runner) as indirect reference. Despite version 106.10.1 is in the correct folder and loaded, runtime rejects it because minor version doesn't match.
The fusion log looks like in attached picture.

Would be very nice if there would be new nuget with specific version.

[gkello]

I would urge You to release next version, either 106.11 or 107 - just to fix the version mess. Today I had to resolve a issue where referenced nuget package was using 106.6.9 while project was updated to 106.10 - and assembly binding redirect did not get created correctly, likely because of version number "downgrade".

[coderjoe]

Has there been any movement on this yet? This is preventing our org from upgrading from 106.6.

Edit:

We have found we are able to upgrade if we tweak the binding redirects generated by nuget and may have to disable automatic binding redirect generation in a few projects. This is caused by 106.6 appearing to be "newer" to our build tools than 106.0, even though 106.0 represents the 106.10 package.

For now it appears we have a work-around, but this introduces a greater maintenance burden as we maintain our projects going forward. I agree with the above comment that releasing a temporary fix as 106.11 that we can upgrade to, and moving the version scheme change to 107 would be beneficial.