reactiveui
[Bug]: refit 9.* removes strong naming
Describe the bug 🐞
- Attempt to build strong named assembly referencing refit 9.0.2
- CSC : error CS8002: Referenced assembly 'Refit, Version=9.0.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.
Version 8.0.0 of refit was strong named.
$ sn -v ~/.nuget/packages/refit/8.0.0/lib/net462/Refit.dll
Mono StrongName - version 6.12.0.199
StrongName utility for signing assemblies
Copyright 2002, 2003 Motus Technologies. Copyright 2004-2008 Novell. BSD licensed.
Assembly .../.nuget/packages/refit/8.0.0/lib/net462/Refit.dll is strongnamed.
Version 9.0.2 is not.
$ sn -v ~/.nuget/packages/refit/9.0.2/lib/net462/Refit.dll
Mono StrongName - version 6.12.0.199
StrongName utility for signing assemblies
Copyright 2002, 2003 Motus Technologies. Copyright 2004-2008 Novell. BSD licensed.
.../.nuget/packages/refit/9.0.2/lib/net462/Refit.dll is not a strongly named assembly.
I have looked at the release notes and the commit log. I was not able to find any announcement of this change or a specific commit where the change was implemented.
Is this a deliberate choice / change by the project or an error in the build and release process for this version?
If this and future versions of the assembly are not going to be strong named, our project will need to move away from using refit as (at least some of) the users of our library require their dependencies to be strong named.
Step to reproduce
- Attempt to build strong named assembly referencing refit 9.0.2
- CSC : error CS8002: Referenced assembly 'Refit, Version=9.0.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.
Reproduction repository
https://github.com/reactiveui/refit
Expected behavior
Assemblies that are strong named can be built referencing new versions of refit.
Screenshots 🖼️
No response
IDE
No response
Operating system
Windows/MacOs/Linux
Version
No response
Device
No response
Refit Version
9.0.2
Additional information ℹ️
No response
It looks like it might have been removed in e954c1817710b0db631fa13ac5da3387005e40fe as part of #1953.
It looks like it might have been removed in e954c18 as part of #1953.
Good spotting! I did not see that one.
* Change Signing doesn't really call out "This assembly will no longer be Strong Name signed" though.
I would definitely class this as a breaking change as previous consumers are blocked from using the library. It would be good for that sort of change to be explicitly called out in release notes.
It's for sure a breaking change, but maybe just a bug. buildtask.snk is still in the repo, so hopefully the maintainers are okay with fixing/adding the signing.
Sorry, I forgot to return the Signing to normal once the build errors had been fixed with VS2022, whenever the signing was enabled, it failed to build, so I removed it to advance things, unfortunately it slipped my mind. Thank you for raising the issue.
Sorry, I forgot to return the Signing to normal once the build errors had been fixed with VS2022, whenever the signing was enabled, it failed to build, so I removed it to advance things, unfortunately it slipped my mind. Thank you for raising the issue.
Thanks for the context. I was unenthusiastic about submitting a patch to re-enable signing without understanding what "Change Signing" entailed.