Sign assembly for a strongly named DLL

[carlreid]

We need to register this DLL in GAC for a 3rd party system to find the DLL. This requires this assemply to be signed so it's strongly named.

[irabinovitch]

@carlreid Thanks for the PR. We're having the team take a look and will respond with feedback soon.

[ogaca-dd]

@carlreid: Thanks for the PR. Everything looks good!

[carlreid]

@ogaca-dd Great! It would be awesome if you could possibly do a minor release so we can consume the package.

Otherwise an indication of when you plan on releasing a new version so we can schedule accordingly.

[ogaca-dd]

@carlreid: We plan to create a new release next week.

[carlreid]

@ogaca-dd Sounds good, thanks for the update 👍

[carlreid]

@ogaca-dd Is the plan still to release this week? We're very eager to get our metrics working.

[ogaca-dd]

Yes the plan is to release tomorrow!

[ogaca-dd]

Hello,

The DogStatsD-CSharp-Client 3.4.0 has just been released: https://www.nuget.org/packages/DogStatsD-CSharp-Client/3.4.0.

https://github.com/DataDog/dogstatsd-csharp-client/blob/master/CHANGELOG.md

[carlreid]

Thanks for the update! Will play around with it on Monday 😄

[darraghjones]

https://haacked.com/archive/2012/02/16/changing-a-strong-name-is-a-major-breaking-change.aspx/

[lucaspimentel]

@darraghjones: Can you add some context to your comment? Did this change cause an issue for you? If so, please open a new GitHub issue.

Regarding strong naming in general, it's been almost 8 years since that post and a lot of things have changed since then. Microsoft has taken several steps to reduce the friction cause by strict binding in .NET Framework:

• NuGet can add assembly binding redirects when a package is added to a project.
• Visual Studio can create assembly binding redirects automatically at build time.
• Modern .NET frameworks like .NET Core, UWP, and Xamarin have more relaxed binding policies or ignore strong names altogether.

Here are some links to more recent official guidance on strong naming assemblies (emphasis mine):

• Strong Name Signing

  Because of the viral nature of strong-naming, it is recommended that publicly published .NET libraries are strong-named. Not strong-naming a .NET library excludes anyone who does need to strong-name their application or library from using it.

• Open-source library guidance: Strong naming

  You should strong name your open-source .NET libraries. Strong naming an assembly ensures the most people can use it, and strict assembly loading only affects the .NET Framework.

[darraghjones]

Yes, the issue we encountered was
System.IO.FileLoadException: Could not load file or assembly 'StatsdClient, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) File name: 'StatsdClient, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null'

The file which was actually deployed was StatsdClient 3.4 (due to transitive dependencies and using a highest matching version dependency resolution strategy).

You cannot use assembly binding redirects to redirect from a non-strongly named assembly to one which is. Admittedly this is a non-issue with .NET Core. But it is still an issue with .NET Framework.

I'm not saying don't strong-name you're assemblies. Just that if you chose to add or remove the strong-naming you should seriously consider major version bumping. I can still remember like yesterday the pain this caused when log4net did the same thing.