RestSharp nuget Assembly version (105.2.3.0) vs RestSharpSigned Assembly version (100.0.0.0)

[jiggle]

First of all, sorry in advance as I know the signed version is not a priority.

Hi - When I install RestSharpSigned via nuget the project reference is added as:

<Reference Include="RestSharp, Version=**100.0.0.0**, Culture=neutral, PublicKeyToken=598062e77f915f75, processorArchitecture=MSIL">
     <HintPath>..\..\packages\RestSharpSigned.105.2.3\lib\net452\RestSharp.dll</HintPath>
     <Private>True</Private>
   </Reference>

When installing RestSharp project reference looks like:

<Reference Include="RestSharp, Version=**105.2.3.0**, Culture=neutral, processorArchitecture=MSIL">
      <HintPath>..\..\..\packages\RestSharp.105.2.3\lib\net452\RestSharp.dll</HintPath>
      <Private>True</Private>
    </Reference>

Is it intentional to have the version 100.0.0.0 on the signed dll or a mistake?

I know I can get round it using assembly bindings, but thought I would ask as I have been getting errors looking for version 100.0.0 file and took me a while to realise the only place that's mentioned is in the dll itself and the project references, everything else refers to 105.2.3

I've attached the what you see in the headers of the 2 dlls when decompiling them.
RestSharp.dll (unsigned)

RestSharp.dll (signed)

Thanks for any info (and also thanks for maintaining a signed version, really helps)

John

[vongillern]

My understanding is that the best practice that seems to be followed by most projects now is to pin the version number of the signed assembly and use Nuget versions to track the "real" version number.

Here is some discussion about it:

http://james.newtonking.com/archive/2012/04/04/json-net-strong-naming-and-assembly-version-numbers

octokit/octokit.net#405

I hate signing and would love to see it disappear entirely. However, the reality is that some applications need it and it is an utter cluster to do some with and some without. RestSharp especially, since it has two nuget packages (one signed, one not) and people have dependencies that have dependencies on both of them separately. This was my issue. Easypost referenced RestSharpSigned, Twilio referenced RestSharp.

If you are in this situation, i've outlined your options here: EasyPost/easypost-csharp#50 (comment)

I personally chose to use the Brutal Developer Strong Name Signer to change all unsigned references to signed references. Here are the steps to follow to do that

[alexeyzimarev]

The develop branch only contains unsigned version. I don't really want to sign it. The download numbers show that unsigned version is much wider used.

[mynkow]

It is sad that it was signed :(

I am thinking about maintaining unsigned version

[alexeyzimarev]

What is the issue with using the signed version? Both signed and unsigned code can use signed assemblies. Am I missing something?

[mynkow]

Once you sign an assembly you cannot use it in binding redirects with previous unsigned versions. We hit pretty nasty problem with this. One of the nuget packages which we had to update also updated its reference to signed RestSharp. This automatically broke all other packages which were still with unsigned version. Basically we are stuck. In other words, until all projects which we use update their RestSharp reference to the signed one we cannot update anything OR we just build custom version of restsharp and custom version of the other project and the other project. To be honest it was a disaster for us.

[alexeyzimarev]

You could have reached me when you got to this problem. There are conflicting requirements from different people. Someone said - just sign it, it makes no harm.

[mynkow]

I think you are right. For now I think that the snk key MUST be public so that anyone who needs to do a custom build could sign the assemblies.

One reference which is interesting point of view => https://www.pedrolamas.com/2016/03/01/still-strong-naming-your-assemblies-you-do-know-its-2016-right/

[alexeyzimarev]

I would love to stop this signing madness. May be from like 107 I will just say that 106 was the last signed version.

[mynkow]

I do never sign my packages but this is me. I hope this is not just another tabs vs spaces. Probably you could ask someone for an advice before removing it.

[mynkow]

Here is a good read => https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/strong-name-signing.md

[alexeyzimarev]

Yeah, I am aware of that. I will consider to stop signing in the next major version. I can always refer to this document and say "Microsoft told me so" :)