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:

1. 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.

2. Strong naming guarantees a unique name for that assembly. Thus no one else can use the same assembly name.

3. 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.