Fluent is not strong named any more.

[CopaDataPM]

There seems to be a intentional change with version 6 in Fluent.Ribbon that assemblies are not strong named any more. All professional software products are strong named to ensure that assemblies are not replaced with any other version. Assemblies without strong name are not usable in that system. By updating to the current version we cannot compile any more without compiling Fluent.Ribbon by ourselves and publish NuGet packages (because we use NuGet Packages).

Please reconsider your decision because it generates pain.

Thanks

[mmgerald]

We have the same issue here - an application that uses Fluent.Ribbon as one of many libraries. Now, we have to compile Fluent.Ribbon...

[mmgerald]

see also #522

[batzen]

It was intentional. This change was announced in August 2017 with #466 and on twitter, gitter and it's the first bold marked entry for breaking changes for version 6 in the Changelog.

Strong naming is not a security feature. It can simply be bypassed by binding redirects.

[mmgerald]

I know that this was intentional, I see the message in twitter, gitter, changelog and #466, but that does not help. The (easy) usage of Fluent.Ribbon is limited because referencing from strong named assemblies is now a mess.

At binding redirects. Not that easy: https://stackoverflow.com/questions/2191296/net-assembly-binding-redirect-with-differing-public-key-tokens

Maybe a solution would be to publish strong named and not strong named assemblies to NuGet?

[batzen]

Still not a security feature. Quote from Microsoft documentation

Warning

Do not rely on strong names for security. They provide a unique identity only.

Strong naming was also removed from ControlzEx as it caused pain points when upgrading to new versions while not upgrading Fluent.Ribbon.

May i ask why you are using strong naming?

[mmgerald]

Maybe a misunderstanding - I don't want to discuss about security.

Strong names provide a unique identity, we have to ensure that our software have a unique identity because many components get embedded in another application (not in our hands) and that application assumes strong-named assemblies ONLY. Many assemblies we have to register in GAC, that is a prerequisite. We have several 100 libraries here, Fluent.Ribbon we use only partly, but we cannot change the whole system, the only chance is to compile Fluent.Ribbon ourselves with strong name...

[batzen]

@ianitor Any idea on how to publish both versions? This would also require to reference two different versions of ControlzEx.

To be honest, i don't need strong naming anymore and i don't want it back because it causes pain when upgrading versions. But i would happily accept ideas and PRs adding it back as a separate nuget package. If you plan to do a PR adding it back please wait till i merged the sdk-csproj changes to develop because the projects for different .net versions will be gone then.

[chrfin]

May take a look at https://www.nuget.org/packages/Brutal.Dev.StrongNameSigner/

[ghost]

WTF?!? I give zero f*** if it's a security feature. It's a unique signature and when I put all my assemblies together, I need a unique signature on each of them. Every other NuGet package I have has unique signatures and when my final assembly links, it expects everyone to have a unique signature. You are intentionally making life harder for us with your misunderstanding of the MS directive.

[punker76]

@Dark-Bond

Strong Naming Considered Harmful : Strong naming bad. Free your bits.

Don't sign your assemblies. They want to be free. Let them live.

• question: "But I heard it was good..." answer: No.

• question: But it was like a whole module in the MCSD course I started 5 years ago... answer: No.

• question: "Wait, signing things and strong naming sounds like a good idea. Convince me." answer: | Consider this all too common occurrence:

  • Your application uses an OSS component called FancyLogging and you’re depending on the latest version 2.1.5.
  • You also use FancyServiceBus that depends on FancyLogging version 2.0.7.
  • You might also have a dependency on FancyIoC which in turn depends on a much older version of FancyLogging 2.0.0.

  Assuming that the authors of FancyLogging are following Semantic Versioning, you should be able to happily use the latest version of FancyLogging because there are no semantically breaking changes between it and the versions that FancyServiceBus and FancyIoC were compiled against. If these assemblies are strong named however, you just set yourself up for a whole lot of assembly version conflicts because .Net matches on the entire version number. At this point, you’re going to be spending some quality time with the Fusion Log Viewer.

  Strong naming conflicts are a common issue when your dependencies improve or change rapidly, and you upgrade somewhat often, and especially when upstream dependencies like log4net, IoC containers, and Newtonsoft.Json are also used by your upstream dependencies.

  (This is borrowed from Jeremy Miller's blog. You can see the original post here.)

• question: But the governance committee says we need to sign our assemblies... answer: | Oh. Ok then.

  ...

  Wait. No.

  insert reasons and workarounds here

• question: "But [cool open source project] doesn't have strong naming and I need it in my enterprise app that I absolutely need to sign..." answer: | Don't hassle the developer to sign their project just so you can use it. There are several workarounds that you can use:

  • Use ILDASM and ILASM to sign the assemblies after the fact.
  • Use Git submodules to fork the project into your project and build it yourself examples please
  • anything else?

• question: "But isn't strong naming a security thing?" answer: | Absolutely not. To quote MSDN, "Do not rely on strong names for security. They provide a unique identity only."

taken from: strongnamingconsideredharmful

And more...

Strong-named assemblies are only useful in some rare scenarios. If you need strong-named assembly then you can compile the source by yourself ore use the Strong Namer from Daniel Plaisted @dsplaisted or Strong-Name Signer from Werner van Deventer @brutaldev.

More informations about the reason of this decision can be found here:

• Still Strong-Naming your Assemblies? You do know it’s 2016, right?
• XAML Behaviors UWP Managed 1.1.0
• Strong-Named Assemblies