Why use strong named assemblies?
What are the advantages of using strong named assemblies?
What are the th开发者_JAVA百科ings that can't be done with a normal assembly?
Let me list the benefits of strong naming your assembly first:
Strong naming your assembly allows you to include your assembly into the Global Assembly Cache (GAC). Thus it allows you to share it among multiple applications.
Strong naming guarantees a unique name for that assembly. Thus no one else can use the same assembly name.
Strong name protect the version lineage of an assembly. A strong name can ensure that no one is able to produce a subsequent version of your assembly. Application users are ensured that a version of the assembly they are loading come from the same publisher that created the version the application was built with.
More on strong naming from Microsoft is in Strong-Named Assemblies (MSDN).
What are the things that can't be done with a normal assembly?
Since all the discussions that started with the rise of Nuget suggested to completely get rid of strong named assemblies my company tried that and came across a significant change of behavior when it comes to application settings:
If you use the automatic app or user scoped application settings provided by VisualStudio (inheriting System.Configuration.ApplicationSettingsBase) then a strong named EXE will create exactly 1 directory inside %LOCALAPPDATA% named for example "YourApplication.exe_StrongName_kjsdfzsuzdfiuzgpoisdiufzsdouif" no matter where the EXE is located.
But without the strong name the location (=path) of the EXE will be used to create a hash value which already differs between DEBUG and RELEASE build, creating many directories inside %LOCALAPPDATA% named like "YourApplication.exe_Url_dfg8778d6fs7g6d7f8g69sdf". This makes it unusable for ClickOnce deployments where the installation directory changes with every update.
I would like to add that without a strong name you cannot use binding redirects in config files.
This will not work:
<dependentAssembly>
<assemblyIdentity name="MyAssembly.MyComponent" publicKeyToken="null" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
</dependentAssembly>
You need to have a public key token
<dependentAssembly>
<assemblyIdentity name="MyAssembly.MyComponent" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
</dependentAssembly>
Just an example: I would like to give an answer doing more emphasis in the security. In the case we create assemblies with a source code that we don't want to be re-used for a third party but we want it to be testable, we can strongly sign an assembly and make the internals visible for only those assemblies with the same signature.
精彩评论