mirror of
https://github.com/brutaldev/StrongNameSigner.git
synced 2026-04-25 11:26:04 +03:00
[GH-ISSUE #83] Fixing unsigned references in signed assemblies when signing unsigned assemblies - unhandled case? #68
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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?
Originally created by @HiddenDude on GitHub (Jan 4, 2023).
Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/83
Originally assigned to: @brutaldev on GitHub.
Hello,
I'm trying to use the strong name signer on a C# project made with the "DYMO.Connect.SDK" NuGet package.
(from https://www.nuget.org/packages/DYMO.Connect.SDK/ , its a label printer SDK )
(that package contains a mix of signed and unsigned DLLs, e.g. in the current version = 1.4.3.37)
(& I'm targeting .NET Framework 4.7.2 in case you need to know for possible testing with the package)
When using the StrongNameSigner NuGet package, the build task doesn't seem to catch all output DLLs.
(some DLLs in the output directory stay unsigned, even though they are referenced somewhere in the dependency tree)
I've also had some problems trying to sign the DLLs by hand with the GUI/CmdLine tool..
Some don't get added to the list at all (GUI) without an error.. And for some there are problems finding referenced assemblies.
(it could be somehow related..? or VS just knows about additional dependant package paths and the manual tools don't..?)
I've mostly already worked around my problem by not signing my class library project and manually renaming a file (DymoSDK.dll.unsigned => DymoSDK.dll) in the NuGet package - that way everything stays unsigned (except for a few calls from unsigned code to signed code which seems to be allowed) and my application doesn't complain.
It would be nice if the strong name signer could even fix shit like the DYMO.Connect.SDK.
(it has already cost me hours)
I suspect the SDK has a reference to an unsigned DLL within an actually signed DLL thats not updated because the tool doesn't touch signed assemblies..?
Let me know if you need more detailed input. I'd have to "break" my project and check the DLLs' dependencies again to know what exactly wasn't correctly signed / updated with the strong name signer build process task.
@brutaldev commented on GitHub (Jan 4, 2023):
Please provide the log output from the signing process. You can also provide the log output when using the user interface/console application for the assemblies that get ignored (mixed-mode or native I suspect).
Do you have a sample project or is it just a basic project that brings in the DYMO.Connect.SDK NuGet package?
Why not just leave things unsigned, is there is a specific reason you need to actually strong-name sign your project?
Unsigned assemblies can use signed assemblies but not the other way around (which is what this tool was created for). If you do not need to sign your own stuff then don't worry about trying to sign others.
@HiddenDude commented on GitHub (Jan 4, 2023):
I have made a quick VS2022 sample project for it and attached it.
(but I had to exclude the actual packages from the zip because of upload size limitations, but they are fresh from the store)
DYMOSDKSampleForSNS.zip
Just a basic .NET Framework class library targeting .NET Framework 4.7.2 with the "DYMO.Connect.SDK" (+ dependencies) and "Brutal.Dev.StrongNameSigner" NuGet packages added, and maybe some short code to initialize the SDK.
The output directory looks complete like that and reproduces the error in my application.
The log from the build process (including SNS notifications) is this - is this log sufficient or did I miss anything?:
It looks like the StrongNameSigner is not even doing that much there.
(the 2 DLLs that it checks are already signed by default if the SDK NuGet package is left unmodified)
But the problematic DLLs seem to be in the "Build" directory of the "DYMO.Connect.SDK" package.
(and those DLLs also are part of the dependency tree of the SDK DLLs. And they also flow into the output directory)
E.g. "DYMO.CrossPlatform.Common.dll".
(DYMO.CrossPlatform.Common, Version=1.4.3.37, Culture=neutral, PublicKeyToken=null)
As far as I can see (with ILspy), the signed "DymoSDK.dll" references it.
(DymoSDK, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8cbe8a3c50c5633e)
Thats what actually is inside the Build directory, but we would need to sign it and fix the reference inside DymoSDK.dll to also point at that signed assembly for my application to not complain because my signed DLL is using unsigned dependencies.
I'm not sure how you could reproduce the actual error with this sample project as I'm actually using the class library as an interop "addin" inside Microsoft Dynamics NAV and talk to the DLL using C/AL code.. Not sure if the same error would appear when trying anything (e.g. call GetPrinters()) from a e.g. WinForms app thats using the DLL.
In my opinion it would be OK to "re-sign" DymoSDK.dll with a new key if necessary to fix the unsigned references.
(but the tool would first have to try to do something with DYMO.CrossPlatform.Common.dll?)
Let me know if you need more information.
EditAdded code block around the log to make it more readable.
@HiddenDude commented on GitHub (Jan 4, 2023):
I've overlooked your additional response in the quote box:
Thats what I'm doing as a workaround for now. Not sign my library = no errors.
Its just usually best practise for NAV DLLs to strong name sign them.
(otherwise there may be issues with deployment later on)
And I never had to not do it because of a 3rd party library. The DYMO SDK may be the first one.
EditAdded a reason to adhere to the best practises in my case in brackets. But that would require using the signed dependency in my signed wrapper DLL. And it's dependencies also all need to be signed, but the SDK doesn't come like that from the vendor.
Somehow their signed main assembly is referencing some unsigned assemblies and no one ever noticed the error internally..
(if I just sign the unsigned assemblies - if it works - my app would no longer find the signed assembly at run time, so the references need to be correct as well)
Thats how I come across StrongNameSigner after reading a post with ildasm/ilasm commands to manually fix stuff like this.
It might not be a bug, but rather 1-2 new features to catch more of those DLLs (also in the VS build task as I'm not using the tools manually?) and also rewrite signed assemblies to fix references to previously unsigned assemblies after signing them - but you now have an example of a bad SDK to possibly harden the tool on. Its not critical for now. But I really like the idea of one automated tool to fix all DLL strong name signing related problems ;)
@brutaldev commented on GitHub (Jan 5, 2023):
They are probably dynamically loading them and not referencing them.
SNS can fix all of this, but if there is no hard reference then there is no way for it to know it also needs to sign these extra assemblies. You will need to specify the list of assemblies you want to sign and will not be able to easily use the automatic build task.
I'll look into this a bit later, I'm still on vacation.
@brutaldev commented on GitHub (Jan 5, 2023):
I think you'll have a lot more luck with v3.3.0.
In your project file you need to remove the target imports and use your own custom one to just sign
DYMO.Connect.SDK..csprojfile:.csprojfile inside the<Project>element:In your test project this builds just fine with no errors/warnings:
You can note the mixed-mode assemblies that are not supported, those are likely the ones being dynamically loaded. You can test this out in your real project and see if it works.