Strong Name

[ymerej]

Paul, is it unreasonable to expect that the ReactiveUI should be strong named so that I can easily use it within a solution where everything is strong named?

I have used ReactiveUI on other projects and it has worked very well. Great framework!

Thanks
Jeremy

[anaisbetts]

If you want to strong name it yourself via building the source you can, but the official release will not be, strong naming is a nightmare

Paul Betts

SENT FROM MY COMMODORE 64: RESPONSES MAY BE IN ALL CAPS

On Jan 17, 2012, at 9:09, ymerejreply@reply.github.com wrote:

Paul, is it unreasonable to expect that the ReactiveUI should be strong named so that I can easily use it within a solution where everything is strong named?

I have used ReactiveUI on other projects and it has worked very well. Great framework!

Thanks
Jeremy

---

Reply to this email directly or view it on GitHub:
https://github.com/xpaulbettsx/ReactiveUI/issues/43

[haacked]

We should discuss. Not strong naming a library is also a nightmare. The nightmare of strong naming is mitigated by NuGet quite a bit.

[wilka]

I know this is an old issue, but I take it the decision is still the same?

I'm in the process of updating to the latest ReactiveUI and the lack of strong means I can't just install it via NuGet (everything in the project I'm working in is strong named)

[kentcb]

I, too, would love to understand this "nightmare" of which Paul speaks. I brought up this problem a while back too, not realizing this issue had been created and subsequently closed.

[fahadash]

We do need strong name for this... Its KILLING ME!!!!

[jen20]

If you need strong naming I assume you're doing WPF, building yourself for that is quite straightforward.

[wilka]

One thing to keep in mind if you do add strong naming yourself, I found (with ReactiveUI 4.5, not sure about newer versions) is that you need to use ServiceLocationRegistration directly because after adding a strong name it can't automatically load the correct assemblies (and I wanted to keep the changes to RxUI to a minimum). So, my app startup code now includes

var reactiveUiServiceLocator = new ReactiveUI.Xaml.ServiceLocationRegistration();
reactiveUiServiceLocator.Register();

[kentcb]

The problem with self-signing is you're forgoing the convenience of NuGet. I ended up removing signing from my entire app because of this. And I'd still love to hear an explanation of why signing is a problem.

[jen20]

Who has the key?

[anaisbetts]

I ended up removing signing from my entire app because of this

That's The Idea™ :)

[fahadash]

This is really killing us. I am building a component using ReactiveUI that will be referenced by an application which is strongly named. In order for that application to reference my assembly, I have to strongly name my own.

I would really love to have the nuget version strongly named so we can get the updates without the hassle.

All component vendors and other nuget packages are built with strong names. Why not nominate someone to have the key or have Microsoft help you with hosting the key and strongly name ReactiveUI ?

[jen20]

Is there a particular opposition to just strong naming it yourself?

[fahadash]

Doing it myself would require me to branch the source and maintain a version on my end. And whenever there is an update on Main/Trunk/Head/Master, it will be a hassle for us to apply those updates as opposed to simply downloading the DLLs from nuget server.

Secondly, If a build is coming from you guys, the stability of the build would be less questionable than the one I make using my computer.

[anaisbetts]

In order for that application to reference my assembly, I have to strongly name my own.

Stop strong-naming your application.

Here's the problem with strong naming. Every time a new contributor comes along, they now have to have an extremely demotivating fight with Visual Studio to get the project to build, or to replace the official binaries with ones they've built for testing. Motivation sapped, for literally zero benefit.

I can't reiterate that enough. There is zero benefit(star) to Strong Naming, only significant downsides that disproportionally affect the Open Source community. If you are concerned about tampering detection and authenticity, you should Authenticode sign your binaries using a proper Code Signing Certificate.

(star) - the only legitimate use of SN is when you have to load more than one version of the same library into an application. This almost exclusively happens with large applications that have plugin support, like Visual Studio.

[AArnott]

@paulcbetts Your argument to not strong-name sign your application is only useful if in fact the user you're talking to is writing an application (and thus is the terminal point for consumption). Yes, an app author can decide to not strong-name sign. And that would probably be fine.

As you say, there are only a couple real tangible benefits to strong-name signing at the app-level. You mentioned one: loading more than one version of the assembly at a time. The one you did not mention is GAC'ing assemblies, which requires that they be strong-name signed. And sure, while there are strong arguments to be made against GAC'ing your assemblies, there are also tangible reasons for some apps to have a presence in the GAC, particularly on older versions of the CLR.

But for library authors, they can't simply decide to not strong-name sign. It's not always up to them. Most likely, they've already shipped and are already strong-name signed. To stop strong-name signing would be a significant breaking change (as not even binding redirects would allow it to work I believe without all consumers recompiling). That would be a very strong point for strong-name signing: keep everything working. No real way around that. Sure, you can argue it was a problem that strong-name signing created to begin with, and perhaps you'd be right, but that doesn't really matter, does it? Regardless of who started the "problem", you are where you are. And you can keep the system running smoothly by continuing to strong name sign. That then limits the existing library author to only depend on other libraries that also strong-name sign.
So should strong-name signing be propagated to those other libraries? Yes. It promotes the open source agenda, which is to share code, get feedback, get more contributions and reduce redundancy.
What is the cost to strong-name signing? I can't think of any. It may require that folks use binding redirects in their app.config files, but that's not really a big problem, especially now when nuget will write all that for them so it's basically automatic.

[jlaanstra]

What is the cost to strong-name signing?

The cost for strong-name signing of ReactiveUI has been clearly stated at http://log.paulbetts.org/a-modest-proposal-strong-naming-carbon-offsets/

The other option is to sign it yourself. It has been stated plenty of times already, but just to repeat it: ReactiveUI will never be strong-name signed.

[AArnott]

@jlaanstra to be clear, I don't use reactiveui and have no interest in whether it strong name signs or not.
You say @paulcbetts states clearly the costs of strong name signing at that link. I've read it. I don't see a single cost stated. He says there are costs, but he doesn't state a single one.

[anaisbetts]

We don't need any more discussion on this.