.NET SDK is not strong named.

[danielwspie]

We have a library of .NET Framework 4.7.2 assemblies that require referenced assemblies be strong named, thus including the NuGet package Keeper.SecretsManager Version 16.4.0 results in the following error:

System.IO.FileLoadException: 'Could not load file or assembly 'SecretsManager, Version=16.4.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required.

Based on this Microsoft documentation from Sept 2021, it recommends You should strong name your open-source .NET libraries. Strong naming an assembly ensures the most people can use it, and strict assembly loading only affects .NET Framework..
https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

Please consider strong naming your .NET SDK assemblies.

[DevOma75]

I have signed the file in my build process but also would like to get a strong named file from Nuget package without manual steps

[maksimu]

Is there still a need for this? We are trying to decide if we should do this or not.

[danielwspie]

@maksimu yes, due to third party dependencies, we will be on this .NET Framework 4.7.2 infrastructure for the foreseeable future, so the inclusion of this will make our interaction with the Keeper library a much easier experience. Also note, this is the only NuGet package we've encountered that isn't strongly named.

[maksimu]

Ok one quick question then, should we publish a new one with a slightly different name ( append “.strongName “ for example), or just have one library published that is strong named. Will it break customers applications that are using our SDKs. Will our strong named application be like a “poison pill”?

…

On Thu, Mar 28, 2024 at 8:39 AM Daniel Watkins ***@***.***> wrote: @maksimu <https://github.com/maksimu> yes, due to third party dependencies, we will be on this .NET Framework 4.7.2 infrastructure for the foreseeable future, so the inclusion of this will make our interaction with the Keeper library a much easier experience. Also note, this is the only NuGet package we've encountered that isn't strongly named. — Reply to this email directly, view it on GitHub <#404 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABNXKT6L6A2IVFLLPTJ4L3Y2Q2TXAVCNFSM6AAAAAAUB2K4LWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRVGUZDGMZUGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[DevOma75]

One library is enough - as it is possible to reference signed assemblies from unsigned projects - the change will not affect anyone who used it in that way. But for all who are working with signed libraries it will be more comfortable - I have to use ildasm and ilasm in my build process to sign the assembly before referencing. That step would not be needed after you sign the assembly in NuGet package - thanks