Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strong Name #43

Closed
ymerej opened this issue Jan 17, 2012 · 18 comments
Closed

Strong Name #43

ymerej opened this issue Jan 17, 2012 · 18 comments

Comments

@ymerej
Copy link

@ymerej ymerej commented Jan 17, 2012

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

This comment has been minimized.

Copy link
Member

@anaisbetts anaisbetts commented Jan 17, 2012

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

@anaisbetts anaisbetts closed this Jan 19, 2012
@haacked

This comment has been minimized.

Copy link
Contributor

@haacked haacked commented Jan 23, 2012

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

This comment has been minimized.

Copy link

@wilka wilka commented Apr 9, 2013

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

This comment has been minimized.

Copy link
Contributor

@kentcb kentcb commented Apr 9, 2013

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

This comment has been minimized.

Copy link

@fahadash fahadash commented Mar 7, 2014

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

@jen20

This comment has been minimized.

Copy link
Contributor

@jen20 jen20 commented Mar 7, 2014

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

@wilka

This comment has been minimized.

Copy link

@wilka wilka commented Mar 7, 2014

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

This comment has been minimized.

Copy link
Contributor

@kentcb kentcb commented Mar 7, 2014

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

This comment has been minimized.

Copy link
Contributor

@jen20 jen20 commented Mar 7, 2014

Who has the key?

@anaisbetts

This comment has been minimized.

Copy link
Member

@anaisbetts anaisbetts commented Mar 7, 2014

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

That's The Idea™ :)

@fahadash

This comment has been minimized.

Copy link

@fahadash fahadash commented Mar 12, 2014

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

This comment has been minimized.

Copy link
Contributor

@jen20 jen20 commented Mar 12, 2014

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

@fahadash

This comment has been minimized.

Copy link

@fahadash fahadash commented Mar 12, 2014

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

This comment has been minimized.

Copy link
Member

@anaisbetts anaisbetts commented Mar 12, 2014

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

This comment has been minimized.

Copy link

@AArnott AArnott commented Jul 26, 2015

@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

This comment has been minimized.

Copy link
Member

@jlaanstra jlaanstra commented Jul 26, 2015

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

This comment has been minimized.

Copy link

@AArnott AArnott commented Jul 26, 2015

@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

This comment has been minimized.

Copy link
Member

@anaisbetts anaisbetts commented Aug 5, 2015

We don't need any more discussion on this.

@reactiveui reactiveui locked and limited conversation to collaborators Aug 5, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants
You can’t perform that action at this time.