Strongly Name the assemblies

[geek0x23]

Is it possible for you guys to strongly name your assemblies? I'm looking to use the RestClient within my ActionMailer.Net library, but I can't because it's not strongly named, and my assembly is. I could distribute my own version, but I'd rather not do that.

Cheers!
Scott

[johnsheehan]

There are no plans to do this. See: http://nuget.codeplex.com/discussions/247827

[haacked]

@SWAJ Do you still need a strong named version of RestSharp or have you moved on? @young what about you?

The reason I bring this up is that a clever solution that the JSON.NET library does is to strongly name the assembly, but lock the assembly version. That way, only the package version changes. This resolves most of the binding redirect pains of using RestSharp.

Of course, it's a one-time breaking change. Check out this discussion about signing WebActivator: https://github.com/davidebbo/WebActivator/wiki/Signing-WebActivator

This would pretty much require that we create a new package name. We'd need to come up with a name for it.

[geek0x23]

No I don't. Honestly I would rather drop strong-naming altogether. If somebody that uses my library needs assemblies strongly named, they can do it themselves.

[Atrejoe]

For me this is still a minor issue, I'm trying to get most of my assemblies signed.

[alexangas]

I would also like to drop strong-naming altogether. Unfortunately I can't! I use RestSharp in a SharePoint project that requires DLLs to be deployed to the GAC and therefore must be strong named.

There is the RestSharpSigned package but it is a community effort and not updated as frequently.

Considering this makes it difficult for some users to keep updated with the latest version of RestSharp, I would really appreciate it if the decision to drop strong naming could be reconsidered? Pretty please! Also wondering what happened in Pull Request #422 related to this?

[sharwell]

Strong names only cause a problem when they are not used properly. Unfortunately it's also easy to misuse them. However, we can't forget the following.

1. Strong-named assemblies can be used by applications that do not have strong names.
2. Assemblies without a strong name cannot be used by assemblies that do have a strong name.
3. Many applications which are otherwise highly extensible, such as Microsoft Visual Studio, use strong named assemblies.

Failing to use strong names for an assembly distributed through NuGet is detrimental to overall usefulness of the package. The solution is simple: understand the limitations of strong names and develop a breaking changes policy and NuGet package specification which eliminates the problems typically associated with strong named assemblies.

1. Configure your package to use a strong name.
2. Use ranged version specifications for your NuGet specification and dependencies. For example, you could say that packages released in the range [1.0, 1.1) will use the same strong name.
3. Specify the AssemblyVersionAttribute, AssemblyFileVersionAttribute, and AssemblyInformationalVersionAttribute. Only alter the AssemblyVersionAttribute when you change the minor version of your assembly, because this value changes the strong name. All versions in the range (1.0, 1.1) (per the above example) would only change the values of the AssemblyFileVersionAttribute and AssemblyInformationalVersionAttribute.
4. If you ship separate assemblies targeting different versions of the .NET Framework, use separate values for the AssemblyNameAttribute in each of those assemblies to support property SxS loading of the strong named assembly. Edit: In many cases it's possible to avoid problems by simply ensuring that the public API surface of libraries that target different framework versions are identical.
5. Do not include any changes in the range (1.0, 1.1) which result in a binary incompatibility for assemblies referencing version 1.0. Avoid changes in this range which result in a source code incompatibility.

[sharwell]

If you have any questions about strong names or the associated policies, feel free to @-reference me and I'll be happy to help review any material.

[hallem]

I've reached out to the owner of the RestSharpSigned nuget package to see what he's doing. I've also offered to take it over and to try and keep it up to date with the core library.

[hallem]

I've got control of the RestSharpSigned package and will update it as soon as nuget comes back online. There are commits from tonight that create a new solution and project files that support the strong naming.

[brondavies]

The problem today is that now I have nuget packages that depend on RestSharp and now I can't add any that depend on RestSharpSigned and vice-versa. 😭