A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)

[Mike-E-angelo]

I am attempting to incorporate Sprache into a .NET Core Project which is strongly named with an .snk file. When I attempt to run a test in this assembly, I get the following exception:

The type initializer for 'ExtendedXmlSerialization.Test.ContentModel.Xml.NameParserTests' threw an exception.
Could not load file or assembly 'Sprache, Version=2.1.1.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)

My knowledge of .NET Core isn't too good. Looking around wasn't too helpful, so I am on here pestering you with my pain instead. 😆

[nblumhardt]

Sprache is unsigned; a PR to add signing would be welcome 👍

[mikehadlow]

Strong naming has all kinds of problems for OSS libraries. See Jeremy Miller's post here for some details: https://jeremydmiller.com/2014/04/28/fubumvc-lessons-learned-strong-naming-woes-and-workarounds/. @nblumhardt, I think we should strongly resist signing Sprache. For the small minority of people who need this, it's open source software, they can simply sign their own copy.

[Mike-E-angelo]

I recall seeing somewhere that there is known convention to deploy signed packages alongside unsigned packages, using the .Signed moniker. So Sprache.Signed in this case. Unfortunately, a quick search didn't show an official recommendations for this, but some examples:

https://github.com/ServiceStack/ServiceStack/tree/master/NuGet.Signed
https://www.nuget.org/packages/Polly-Signed/

You can see above that one approach is to make signed versions of the package and check them in, and another creates it via build script.

I ran a search for the .nuspec in the repo here and nothing turned up, so it seems that this process is handled outside of GitHub? Otherwise I would be happy to help out here with a PR for Sprache.Signed.

[mikehadlow]

I have no problem with signed and unsigned version living together in harmony :) If you can do a PR that supports that you have my full support.

[Mike-E-angelo]

Awesome, @mikehadlow I will definitely assist if I can. As noted above, there doesn't appear to be a nuspec in the repo. Does this get handled externally to GitHub?

[mikehadlow]

@Mike-EEE, I think @nblumhardt does something in AppVeyor to do the NuGet upload.

[nblumhardt]

Ick, the ol' strong-naming problem ;-)

I agree there's no real value in strong naming, except that it permits authors of strong-named libraries to easily consume the package.

I don't think there's a huge downside of using it though. Jeremy's post misses the observation that strong naming only causes version conflicts if the version actually changes. In libraries I've shipped recently, I've ended up:

• Turning on strong naming
• Setting AssemblyVersion to a fixed value, e.g. 1.0.0.0, that never (or almost never) changes
• Rev'ing the package/informational/file versions with each new release

NuGet package/informational/file versions cover the need to identify the version of an assembly without the annoying semantic problems that the assembly version presents.

I don't personally think a .Signed improves things enough to justify maintaining two separate packages and the build muck that's required. At some point consumers will still hit some kind of issue, e.g. the one where both incarnations of the package are pulled in, and it becomes tedious to describe types in either since they carry the same name/namespace. More support :-(

What about just using https://github.com/dsplaisted/strongnamer, instead?

[Mike-E-angelo]

Ahhhhh I haven't seen any noted drawbacks or complaints with OSS projects using .Signed, but I concede that I haven't really looked all that much. Since it seems you are in charge of the build process and there is no way to PR my assistance towards the matter, it looks like your suggestion to use strongnamer is the winner here, @nblumhardt. :) Please feel free to close this issue if you feel it has been resolved.

[Mike-E-angelo]

BTW, I have to say that this project is absolutely fantastic! I was able to add it and incorporate it with incredibly little friction, this issue aside. Really excellent work here. 👍

[mikehadlow]

Sorry @nblumhardt and @Mike-EEE , I really disagree. I understand your problem @Mike-EEE but you are the first (and only) person to be bothered by the fact that Sprache isn't strong named out of now 74,000 downloads on NuGet. It will be a pain for all the other users if we strong name it, and simply messing up the version numbering to accomodate it is just further evidence that it would be a poor descision. I really think that for the very small number of users that need signed assemblies, there's nothing to stop them from building their own version. If there's no real value, then why do it?

Oh and thanks for the kind words @Mike-EEE. I know I'm disagreeing with you on this point, but I really appreaciate your input. :)

[Mike-E-angelo]

Hey no problem @mikehadlow, that's what this is all about, right? What's good for other projects may or may not be the best for your project, and vice versa. It's understandable to see perceived unwelcomed overhead for adding a new package. To me it seems that is not an issue, but I don't have 74k downloads under my belt so what do I know? 😆

[nblumhardt]

@mikehadlow I think we disagree on principles but not the course of action - I'm just as happy to close this one with no changes, I'd just prefer not to ship a whole extra assembly for that 1/74,000 case :-)

(StrongNamer really is a pretty excellent solution to this issue that puts the power in the consumers' hands, so in the long run I think pointing people there will be better for the ecosystem overall anyway.)

Cheers!