Giter VIP home page Giter VIP logo

Comments (18)

anaisbetts avatar anaisbetts commented on March 28, 2024

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, [email protected] 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

from reactiveui.

haacked avatar haacked commented on March 28, 2024

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

from reactiveui.

wilka avatar wilka commented on March 28, 2024

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)

from reactiveui.

kentcb avatar kentcb commented on March 28, 2024

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.

from reactiveui.

fahadash avatar fahadash commented on March 28, 2024

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

from reactiveui.

jen20 avatar jen20 commented on March 28, 2024

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

from reactiveui.

wilka avatar wilka commented on March 28, 2024

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();

from reactiveui.

kentcb avatar kentcb commented on March 28, 2024

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.

from reactiveui.

jen20 avatar jen20 commented on March 28, 2024

Who has the key?

from reactiveui.

anaisbetts avatar anaisbetts commented on March 28, 2024

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

That's The Ideaβ„’ :)

from reactiveui.

fahadash avatar fahadash commented on March 28, 2024

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 ?

from reactiveui.

jen20 avatar jen20 commented on March 28, 2024

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

from reactiveui.

fahadash avatar fahadash commented on March 28, 2024

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.

from reactiveui.

anaisbetts avatar anaisbetts commented on March 28, 2024

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.

from reactiveui.

AArnott avatar AArnott commented on March 28, 2024

@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.

from reactiveui.

jlaanstra avatar jlaanstra commented on March 28, 2024

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.

from reactiveui.

AArnott avatar AArnott commented on March 28, 2024

@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.

from reactiveui.

anaisbetts avatar anaisbetts commented on March 28, 2024

We don't need any more discussion on this.

from reactiveui.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.