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.