Closed HavenDV closed 3 years ago
Hi @HavenDV ,
So you are proposing to strong name as a separate nuget package, right?
No. I suggest that you add the strong name to this package. These are just temporary alternatives.
Ok, sorry for not expressing myself clearly. I think we both agree on adding a strong name package. I would go about this by publishing a separate package just like you did but from this very repo.
Since you already have the workaround. Would you like to submit a PR?
The most correct way is to simply add the strong name to the main library. But if you want to release a separate package, here is the code I used: https://github.com/HavenDV/NuGet.NativeLibraries/tree/main/src/FontAwesome.Sharp.StrongName
Ok, since we have no other dependencies i will add "public signing" using a .snk-file. Note that this is not really strong name signing.
Will be available with the next version of FontAwesome font (>5.13)
@mkoertgen How is the status of this topic? As far as I can see the issue was fixed but no new NuGet Packages were created since then. Is it possible to update the Packages?
Hi @felsenbirne,
Exactly right. We waited for 5.15.4 of Font Awesome to come out and missed the point a few months ago ;-)
Here you go:
@HavenDV created a seperate package https://www.nuget.org/packages/FontAwesome.Sharp.StrongName
I would offer to take ownership of the said package. ID Prefix reservation would come in handy here
Instead it is probably easier to just strong name signing using the Brutal signer starting with v6+, cf. milestone
I gave you the rights to the NuGet package. You may also find the source code I used when publishing this package useful: https://github.com/HavenDV/NuGet.NativeLibraries/tree/main/src/FontAwesome.Sharp.StrongName
I also assume that you just need to remove this code to avoid problems on the users side:
<PublicSign>true</PublicSign>
Reviewed MS recommendations again: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming They are advising against publishing two separate libraries
Yes, I or you can hide this library as soon as your library's strong-name is ok. Let me remind you that PublicSign has disadvantages: https://github.com/dotnet/runtime/blob/main/docs/project/public-signing.md
Thanks, as mentioned public signing seems to prevent installing into GAC which. Not sure if it could still be used within DCOM scenarios like Offic-AddIns or for ClickOnce Publishing.
https://www.pedrolamas.com/2016/03/01/still-strong-naming-your-assemblies-you-do-know-its-2016-right/
Please see him update: Update: Though the information and concerns in this blog post are still very true, I’ve actually had a change of heart and I’m now advocating to Start Strong-Naming your Assemblies!!
https://www.pedrolamas.com/2018/09/11/start-strong-naming-your-assemblies/
Also, the absence of a strong signature blocks the distribution of WinForms controls with designers containing icons via NuGet
Temporary alternatives: Signing NuGet package libs before use:
Or my StrongName NuGet package: