Is there a reason we don't want the main package signed? about mathnet-spatial HOT 8 CLOSED

Assuming this is about strong names: having to deal with strong named assemblies "in the real world" is its own kind of hell, and is incompatible with semantic versioning. I strongly advise against it.

Regarding code signing, I've started to do that with Numerics (since v4.0.0-alpha02) and am ok with it, but it means that all maintainers that wish to do releases by themselves would need a (non-free) code signing certificate.

from mathnet-spatial.

and is incompatible with semantic versioning
What do you mean?

from mathnet-spatial.

Strong naming's main goal is that you enforce exactly the same binary at runtime that you have compiled against (or fail). Semantic versioning's main goal is that you can use any version at runtime, provided it is compatible to the one you compiled against according to some simple rules. These goals are opposite to each other.

A workaround is to use a fixed assembly version for all versions. But since that renders the whole point of strong names moot, why do strong naming in the first place (and lose proper assembly versioning)?

from mathnet-spatial.

(Sorry for beeing somewhat emotional on this topic, but have wasted a lot of time at work related to pointless strong naming issues. There are use cases where binding redirects simply don't work or are not feasible.)

from mathnet-spatial.

I started signing my things recently, guess I'll be bitten soon. Only reason I sign things is so they can be used from other signed things. Is the problem you are talking about when updating without recompiling?

from mathnet-spatial.

Yes, e.g. when you use a lot of NuGet packages, also for internal components. The problem starts once you use two packages that both have a dependency on the same other strong-named package, but a different minor version of it. It's usually not much of a problem in a library or in smaller solutions, but can become complicated in large solutions using a lot of packages, and extra-complicated if you cannot resolve this with binding redirects for technical reasons.

from mathnet-spatial.

Based on NuGet statistics, about 5% downloaded the strong-named one, 95% the main one. So there does seem to be some demand for strong naming. The separation is very unfortunate since it also causes potential problems for such diamond-shaped dependencies, e.g. if one of them uses the strong named one. So I do see your point.

from mathnet-spatial.

I'm closing this now, was mostly curious, what we have now is fine with me.

from mathnet-spatial.