starred/sharpcompress
1
0
Fork 0
mirror of https://github.com/adamhathcock/sharpcompress.git synced 2026-02-08 05:27:04 +00:00
Code Issues 975 Packages Projects Releases 20 Wiki Activity

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

New Issue
Closed
opened 2026-01-29 22:06:45 +00:00 by claunia · 13 comments
claunia commented 2026-01-29 22:06:45 +00:00
Owner
Copy Link

Originally created by @kimnzl on GitHub (Aug 5, 2016).

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

Originally created by @kimnzl on GitHub (Aug 5, 2016). In the NuGet package all the assemblies in the 0.12.3 package are not strong named.
claunia commented 2026-01-29 22:06:46 +00:00
Author
Owner
Copy Link

@adamhathcock commented on GitHub (Aug 6, 2016):

People still use strong naming?

@adamhathcock commented on GitHub (Aug 6, 2016): People still use strong naming?
claunia commented 2026-01-29 22:06:46 +00:00
Author
Owner
Copy Link

@kimnzl commented on GitHub (Aug 6, 2016):

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.

@kimnzl commented on GitHub (Aug 6, 2016): 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.
claunia commented 2026-01-29 22:06:46 +00:00
Author
Owner
Copy Link

@catester commented on GitHub (Aug 9, 2016):

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.

@catester commented on GitHub (Aug 9, 2016): 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.
claunia commented 2026-01-29 22:06:46 +00:00
Author
Owner
Copy Link

@kimnzl commented on GitHub (Aug 9, 2016):

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.

@kimnzl commented on GitHub (Aug 9, 2016): 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.
claunia commented 2026-01-29 22:06:47 +00:00
Author
Owner
Copy Link

@adamhathcock commented on GitHub (Aug 9, 2016):

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.

@adamhathcock commented on GitHub (Aug 9, 2016): 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.
claunia commented 2026-01-29 22:06:47 +00:00
Author
Owner
Copy Link

@anaisbetts commented on GitHub (Aug 23, 2016):

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.

:clap::clap::clap::clap::clap::clap:👏

@anaisbetts commented on GitHub (Aug 23, 2016): > 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. :clap::clap::clap::clap::clap::clap::clap:
claunia commented 2026-01-29 22:06:47 +00:00
Author
Owner
Copy Link

@jskeet commented on GitHub (Nov 15, 2016):

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.

@jskeet commented on GitHub (Nov 15, 2016): 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.
claunia commented 2026-01-29 22:06:47 +00:00
Author
Owner
Copy Link

@adamhathcock commented on GitHub (Nov 15, 2016):

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!

@adamhathcock commented on GitHub (Nov 15, 2016): 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!
claunia commented 2026-01-29 22:06:47 +00:00
Author
Owner
Copy Link

@jskeet commented on GitHub (Nov 15, 2016):

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.

@jskeet commented on GitHub (Nov 15, 2016): 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.
claunia commented 2026-01-29 22:06:47 +00:00
Author
Owner
Copy Link

@adamhathcock commented on GitHub (Nov 15, 2016):

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.

@adamhathcock commented on GitHub (Nov 15, 2016): 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.
claunia commented 2026-01-29 22:06:48 +00:00
Author
Owner
Copy Link

@kimnzl commented on GitHub (Nov 15, 2016):

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.

@kimnzl commented on GitHub (Nov 15, 2016): 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.
claunia commented 2026-01-29 22:06:48 +00:00
Author
Owner
Copy Link

@adamhathcock commented on GitHub (Nov 16, 2016):

@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 commented on GitHub (Nov 16, 2016): @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.
claunia commented 2026-01-29 22:06:48 +00:00
Author
Owner
Copy Link

@adamhathcock commented on GitHub (Nov 30, 2016):

Fixed here: https://github.com/adamhathcock/sharpcompress/pull/195

@adamhathcock commented on GitHub (Nov 30, 2016): Fixed here: https://github.com/adamhathcock/sharpcompress/pull/195
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
duplicate
enhancement
feedback requested
not bug
pull-request
Mirrored from GitHub Pull Request
 question
up for grabs
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/sharpcompress#113
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?