.NET assemblies are not strong named in the NuGet Package 0.12.3

[kimnzl]

In the NuGet package all the assemblies in the 0.12.3 package are not strong named.

[adamhathcock]

People still use strong naming?

[kimnzl]

I am currently am but can swap to not using it if it is not going to be used going forward.
I have been revising using it recently.

[catester]

Yes, strong naming is still used because it's still in the .NET framework assembly loader (verification), for instance my app build is now unexpectedly broken due to this error:

Could not load file or assembly 'SharpCompress, Version=0.12.3.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)

This is a .NET related error. Strongly named assemblies (aka signed assemblies) can only reference other strongly named assemblies. Strongly named assemblies can not reference simply named assemblies (aka unsigned assemblies).

So it's a breaking change if you make SharpCompress unsigned all of a sudden, you should have better documented the change in the version history.

[kimnzl]

When I was updating mine I had to go back to one of the 0.11.x series to get a strong named one.
Otherwise I just grabbed the source and compiled the dlls with the addition of signing. I have changed to not using it currently. Maybe have 2 NuGet packages (or releases on GitHub) and add to the ReadMe and changelog about how to get strong named assemblies.

[adamhathcock]

You're welcome to do pull requests to fix this. I don't have time. I accept pull requests all the time.

I pick and choose what interests I can do with what little free time I get and strong naming is not an interest.

Frankly, I believe strong naming is useless and shouldn't be used.

[anaisbetts]

I pick and choose what interests I can do with what little free time I get and strong naming is not an interest.

Frankly, I believe strong naming is useless and shouldn't be used.

👏👏👏👏👏👏👏

[jskeet]

Another request for it to be strong-named... to avoid the warning I'm getting depending on a non-SN assembly from a SN-one in Noda Time. (The one I'm using SharpCompress from has to be strong-named so that NodaTime.dll itself can be strong-named.) I understand the reasons why it's not useful, but there are basically legacy requirements here :(

This should be a simple change though - I'll try to find time to create a PR for it.

[adamhathcock]

I'll happily accept a pull request for this.

I was just slightly annoyed someone wanted me to do it and I didn't have time to figure it out. I have/had a key file I was using so I may switch it to that when you do the pull request.

Thanks!

[jskeet]

One quick feasibility check first: are you still performing your release build on Windows? I've been bitten by Linux builds silently "open source signing" instead of full signing binaries. If you're doing a release build on Windows, it shouldn't be an issue.

[adamhathcock]

Yeah, the build is on AppVeyor just for the full .NET builds.

Doing it locally is harder because I'm OS X only currently. Better fire up that VM.

[kimnzl]

I apologise for being annoying. It was more that I thought that the strong naming had got lost during the upgrade of the VS project to a newer version.
I have since changed my project to not use strong naming.

[adamhathcock]

@kimnzl sorry, I wasn't directing that at you. I was just lamenting people asking for things when a PR could do it easily.

Strong naming kind of did get lost because I changed the project type and it was annoying to figure out.

[adamhathcock]

Fixed here: #195