FluentValidation package now has a Strong Name

[daniellittledev]

It appears that the latest version of the package now has a Strong Name.

Assembly FluentValidation, Version=7.0.0.0, Culture=neutral, PublicKeyToken=7de548da2fbae0f0

Because previous versions did not, there is no way to add a binding redirect to the new version.

This is a major breaking change and looks undocumented. Should this package even be strong named?

[JeremySkinner]

It is clearly documented in the release notes that 7.x is a major release with breaking changes (both due to localization changes and the strong naming)

https://www.nuget.org/packages/FluentValidation/7.0.0

Going forward this adds better compatibility (as both strong named and non-strong named consumers will be able to use it without a separate package).

The AssemblyVersion will stay as 7.0.0.0 even when the nuget package version increments, so binding redirects won't be needed for going from 7.0 to 7.x.

[daniellittledev]

Ah sorry, I see the signed note now. I was just searching for the words "Strong Name".

This is still, however, a painful change for anyone that depends on a Packages which depends on a pre version seven FluentValidation package.

AppReferencesFluentValidation -> AlsoReferencesFluentValidation -> FluentValidation

May I suggest adding a help page targeting the terms.

Assembly Binding Redirect FluentValidation, Version=6.4.X

Which reminds people Binding Redirects don't work for non-strong-named assemblies so they'll have to recompile all dependencies to migrate to 7.0.0

[JeremySkinner]

Yes that's a good idea - I'll try and add a wiki page today for this.

I do understand that it's a pain to make this change (personally I dislike strong naming), but it's a one-time thing.

I do think this l the best way to be able to provide the best support....the previous approach I used was to have 2 packages (FV and FV-signed) but this is much worse for managing dependencies (e.g. If package X depends on FV and package Y depends on FV-signed, and you need to use both X and Y in your project)

Thanks for understanding

[daniellittledev]

For future reference: https://www.pedrolamas.com/2016/03/01/still-strong-naming-your-assemblies-you-do-know-its-2016-right/

[JeremySkinner]

Thanks, I am actually very aware of the issues associated with strong naming. I don't particularly like it and agree it's not ideal, but that article misses a couple of important issues that I'd like to clarify.

1. if your project is strong named, you cannot depend on unsigned assemblies.

There are still many companies out there that for one reason or another have a policy/requirement that all code is strong named. This means that or if libraries (such as FluentValidation) only provide unsigned packages, these developers/companies can't use it without recompiling it themselves, which is a pain as it means they can't use nuget etc. The goal here is to make FV as accessible as possible.

2. the article makes some in incorrect statements about JSON.net and how they deal with signing.

It states that json.net used to be signed "several years ago". Actually, it's still signed, which is why aspnetcore can take a dependency on it (all the aspnetcore assemblies are signed - see https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/strong-name-signing.md ).

However one important point is that Json.net does not increment the assembly version with each release (only the assemblyfileversion/package version). This means no versioning dependency issues and no need for binding redirects. The current stable release of json.net is 10.0.3, but the AssemblyVersion remains at 10.0.0.0. This is the same approach FV will be taking - all the 7.x builds of FV have an AssemblyVersion of 7.0.0.0.

3. Can this be solved with 2 packages? (Signed/unsigned)

Not specifically mentioned in the article, but worth saying again....having 2 versions of the same package (signed and unsigned) doesn't work. It breaks nuget and the dependency graph if one dependency depends on the signed package and another depends on the unsigned package. You can't even do a binding redirect here.

In the end, providing a signed assembly is still the best option to provide the best compatibility. Both signed and unsigned consumers can use a signed assembly, and if the AssemblyVersion is not incremented then there's no need for binding redirects and hot-patching a dll is still possible. Note that this is really only relevant for library authors whose library could be used in either scenario. End user/consumer projects should really always opt for unsigned. Maybe one day strong naming will completely go away. That'd be great. Until then, this is the approach that causes the least friction.

Hope that makes sense.