StrongName signed assembly? Hey, it's 2017...

[batzen]

Fluent.Ribbon v6.0 will not be strong-named.

Why?

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.

More Informations about the reason of this change 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

[ncksol]

That's very unfortunate news. Fluent Ribbon is used in software built with WPF, so none of the reasons above are valid in this case. And you still need to have all your libraries strong-named if you want to get Microsoft's "Windows Certified" batch (which is a requirement in some enterprise cases).

[batzen]

Well, if you need a version with a strong name you can use Strong Namer.

The reasons above are valid. There were already issues with ControlzEx because of strong naming, so it's a real problem.

And you still need to have all your libraries strong-named if you want to get Microsoft's "Windows Certified" batch (which is a requirement in some enterprise cases).

Could you point me to the documentation stating this?

[ncksol]

Sorry I can't seem to find the document. Granted we did the certification maybe five or more years ago, things might have changed since than.
I am still stuck with strongly named libs because I have to load them into Outlook process. Strong Namer didn't work for me for some reason, but I've signed and built the sources for ControlzEx and Fluent from my fork successfully.

[batzen]

I am sorry you had problems with the removal of strong naming on this lib.
But strong naming has to end at some point in time.

[ghost]

No. Your reasons are insane. Because it doesn't work on Windows Phone and Silverlight, it's not useful anywhere? That's really pathetic logic. Look, maybe you've got something. Maybe everyone else is wrong and you're right. Why don't you let someone else start the revolution? You've just screwed up what was a useful library. I've got something like 20 different packages in my WPF solution, so how come yours is the only one that kicks out during a build?

[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

[konne]

@punker76
But he has changed his mind Still strong Name
This is the new article Start Strong Name your assemblies

[batzen]

@konne you should first look for new issues and not comment on closed issues, especially if there are new issues and an entry in the changelog talking about the re-addition of strong naming to Fluen.Ribbon as well as MahApps.Metro.