In some scenarios you might need to strong-name your assemblies - more on strong-naming and why you might need it
However strong-naming your assemblies could introduce some inconveniences in your development process. To strong-name an assembly you need to have access to the public & private key during build time.
Tools like StrongNamer help a lot with your 3rd party unsigned dependencies. Helps tackle the virality character of strong-naming.
In some scenarios you'll want only a few individuals in your organization (Enterprise and less likely in OSS, but still possible) have access to the private key in order to verify identity of an assembly.
In those scenarios where you don't want to share the private key publicly (i.e. in GitHub OSS) or with your entire dev team (Enterprise context), but you also don't want to disturb the dev process, before public signing (introduced in VS 2015 Update 2 compiler) you would have only one option - to delay-sign your assemblies.
Delay-signing your assemblies still introduce a bit of friction in the dev process in the case when you value your private key(ultimately assemblies identities). Everyone that needs to build and run this will have to register this assembly for assembly verification skipping on the runtime(using "sn –Vr myAssembly.dll" command with admin permissions).
Getting to the Public Signing approach. It appears to be flavored alternative of the delay-signing approach. So public signing an assembly is the same as delay-signing one but your dev team won't need to execute the "sn –Vr myAssembly.dll" command on their machines. However, it comes with some limitations:
Known issues when debugging and testing public signed assemblies on
.NET Framework:
- You will not be able to install the assembly to the Global Assembly Cache (GAC)
- You will not be able to load the assembly in an AppDomain where shadow copying is turned on
- You will not be able to load the assembly in a partially trusted AppDomain
*Note on assembly identity:
Strong-naming is for assembly identity and not security. Strong-named (fully signed) assembly would withstand a verification check (i.e. "sn -vf myAssembly.dll") and this would verify the assembly and all of its content is as is it was when it was signed.
Not a security thing since it's fairly easy to bypass the runtime assembly loading strong-name verification for a particular assembly in some contexts at least.