[Bug]: DLL files in **Signed** NuGet packages are not signed.

[IADTIL]

The libraries in the *.Signed NuGet packages (65.22.6.152) are not signed.

[Wagnerp]

Hi @IADTIL

The 'signed' packages mean that the namespaces within these libraries are true and not have been altered somewhere along the line i.e. a strong name. These packages are intended for developers who were coming over from the original toolkit, as this was a by-product of the DLLs. Please see this article for details.

[IADTIL]

Thanks for the link to the article, but I know what signed (strongly named) means. The point is that the dlls in the packages that claim they are signed, are NOT signed (or were not, if you have fixed them now?). When I tried to use them with a project that requires strongly named assemblies (because all my assemblies are signed) link them to a project that used, it wouldn't let me.

Instead I had to download the source, add the projects into my solution, and compile them that way, which defeats the object of nuget packages, and is not ideal because it means differently compiled assemblies with the same version number will be out there.

Have you fixed this now, or did you simply assume I don't know what "signed" means? If there have been no changes to the packages, don't simply mark this as a question. It's a definite bug.

Unfortunately I am now off that project, and am unlikely to be able to test it in future, unless I try it in a personal capacity.

Cheers.

[Wagnerp]

Hi @IADTIL

Thanks for the reply. It might be a bug with NuGet, if so then one option is to package the DLLs into an installer and then put it into the releases section. Sorry for the confusion :).

[mbagattini]

Checking in just to add that I had the same issue too (worked around with the same solution). Happened a few months ago, don’t know the state of this today. Il giorno dom 23 ott 2022 alle 18:56 Ian ***@***.***> ha scritto:

…

Thanks for the link to the article, but I know what signed (strongly named) means. The point is that the dlls in the packages that claim they are signed, are NOT signed (or were not, if you have fixed them now?). When I tried to use them with a project that requires strongly named assemblies (because all my assemblies are signed) link them to a project that used, it wouldn't let me. Instead I had to download the source, add the projects into my solution, and compile them that way, which defeats the object of nuget packages, and is not ideal because it means differently compiled assemblies with the same version number will be out there. Have you fixed this now, or did you simply assume I don't know what "signed" means? If there have been no changes to the packages, don't simply mark this as a question. It's a definite bug. Unfortunately I am now off that project, and am unlikely to be able to test it in future, unless I try it in a personal capacity. Cheers. — Reply to this email directly, view it on GitHub <#817 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHF4LDSAM3ITUGTS55V7YLWEVU5BANCNFSM6AAAAAAQSE5C3Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Wagnerp]

Hi @mbagattini

It is supported, but I think NuGet somehow strips it out.

[Wagnerp]

Hi @IADTIL & @mbagattini

Would you mind testing these DLL files, to verify that they've been signed? Thanks!

[IADTIL]

Hi @IADTIL & @mbagattini

Would you mind testing these DLL files, to verify that they've been signed? Thanks!

None of them are.
You can test them for yourself using the strong name tool, sn.exe.

E.g.
"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\sn.exe" -v "C:\Signed\net462\Krypton.Docking.dll"

I used Powershell to run it on all the dlls from that zip file, with the same result for all of them:

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

C:\Signed\net462\Krypton.Docking.dll does not represent a strongly named assembly

PS.

Running sn.exe on the dlls compiled by the projects included in my solution gives me this result, for example:

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Assembly 'C:\Delivery\Files\ComponentFactory.Krypton.Docking.dll' is valid

Cheers.

[mbagattini]

Just for clarity, I'm not actually testing the dlls. Pinging Ian: @IADTIL

[Wagnerp]

@mbagattini Sorry my mistake.

@IADTIL Thanks for your reply. If it works when you compile it, would you mind sharing the steps that you take to get there? Thanks.

[IADTIL]

@mbagattini Sorry my mistake.

@IADTIL Thanks for your reply. If it works when you compile it, would you mind sharing the steps that you take to get there? Thanks.

As I recall, I downloaded the source code, then simply copied the projects that I required (component projects under Krypton-master\Source\Krypton Components) into my solution and linked to the projects, instead of adding the NuGet packages to my projects. The Krypton projects are then compiled at the same time as my own code, and the dlls copied from that output. (I recall I did change the output location of the projects, as they put them into a bin folder further up the tree). The projects are already set up to sign the assemblies, so I don't understand where the unsigned versions are coming from, or why you would even want to use unsigned assemblies anyway. Why not make the signed assemblies the standard? (Unsigned assemblies can reference signed assemblies, but signed assemblies cannot reference unsigned ones).

Cheers.

[Wagnerp]

I think I'll make them signed as standard to keep it simple.

[IADTIL]

I think I'll make them signed as standard to keep it simple.

Great!

[Wagnerp]

On second thought... found the bug...

[Wagnerp]

Success!!

[Wagnerp]

Resolved - 24/10/2022