Hello,
I would like to use the GSF.COMTRADE NuGet-Package in a strongly named .NET Framework application. This requires that the assemblies in the GSF.COMTRADE package (and its dependencies) are strongly named as well. Since there is already a strong name signing key present in the repository I wanted to ask if signing the GSF assemblies with a strong name is an option for you.
Kind regards,
Malte
All GSF assemblies are digitally signed with a DigitCert certificate:
However, we do not use the strong name on DLL’s on our NuGet packages since this creates the requirement all our other referenced assemblies to also have a strong name - i.e., no use of other assemblies without a strong name. Although our third-party references are very small, they are not zero - so these assemblies would need replacement.
Generally speaking, one of the benefits of a strongly named DLL is the ability to store it in the Global Assembly Cache (GAC) – this because it gives the assembly a “unique” identity – note, however, that it provides “zero” security. As such, there is little reason to have our assemblies that are easily referenced via NuGet to also be registered in the GAC – and, actually having our assemblies in the GAC and/or strongly-named cause more issues than it solves, e.g., with binding policies. FYI, there is a strong name key in the repo, as you noticed – we experimented with this early on, but this caused many deployment issues.
Note that most applications do not need strong-names, see the following article: Strong Name Signing
“Strong-names are left over from previous eras of .NET where sandboxing needed to differentiate between code that was trusted, versus code that was untrusted. However in recent years, sandboxing via AppDomains, especially to isolate ASP.NET web applications, is no longer guaranteed and is not recommended.”
The article also clearly articulates the “issues” we had with strongly named assemblies at the bottom of the page. These issues are the key reasons we do not use strong names - they are listed in order of severity, each one adding more pain than the previous…
Hope that helps!
Thanks,
Ritchie
FYI - we have consequently removed our strong signing key from the repo to avoid confusion. As noted, this was left over from prior experimentation, and we had long lost our private key associated with that old public key anyway.
If your application really must use strong names, one option is to build the library yourself with your own strong name key, given the code is open source. However, in doing so, we would recommend renaming the assemblies to something other than “GSF”, for example, renaming GSF.COMTRADE to MyCompany.COMTRADE, otherwise conflicts may occur with applications using the assemblies with same name that may be installed on the same machine. Additionally, for any third-party DLLs that are referenced by GSF, these will not have a strong name, so references to this code would need to be removed or replaced.
Thanks,
Ritchie
Thank you for your extensive answer.
Since we rely on the identity provided by strong name signing our assemblies changing this is (currently) no option and so far we had no trouble with dependencies from NuGet. However I can undestand your arguments for not using strong names and we will review our remaining options.
Thank you again,
Malte
