Strong Name Bypass

Many managed applications start up slower than they really need to because of time spent verifying their strong name signatures.  For most of these applications, the strong name verification isn't buying the application anything - especially fully trusted desktop applications that are using C# as a better C++.

Since these applications were paying the cost of verifying their assemblies at load time, but were not receiving any benefit from that cost, we've made a change in .NET 3.5 SP1 which lets these applications bypass strong name signature verification.

Specifically, for any assembly which is:

  1. Fully signed (delay signed assemblies still require a skip verification entry)
  2. Fully trusted (without considering its strong name evidence)
  3. Loaded into a Fully trusted AppDomain
  4. Loaded from a location under the AppDomain's ApplicationBase

The CLR will no longer verify the assembly's strong name when it is loaded.

This provides an assembly load performance win for most full trust applications, however not all applications will want to have their fully trusted assemblies skip strong name verification.  If your application wants to re-enable strong name verification, it can add a .exe.config file with the following setting:

        <bypassTrustedAppStrongNames enabled="false"/>

Also, if a machine administrator wants to disable strong name bypass for all assemblies loaded on a particular computer, they can set the DWORD registry value named AllowStrongNameBypass to 0 under the HKLM\Software\Microsoft\.NETFramework key:


(The usual disclaimers apply about modifying the registry only if you know what you're doing)

As with other strong name configuration, on a 64 bit machine this registry setting will need to be set in both the 32 and 64 bit HKLM\Software keys.

For users who have the SDK installed, SN.exe also adds an option to query and update this key for you.  You can run SN -Pb [y|n] to allow or disable assemblies from bypassing strong name verification on your machine. (Again, using both a 32 and 64 bit SN.exe on 64 bit machines).  SN -Pb with no argument will display the current value of the setting.

Comments (5)
  1. Smith says:


    But StrongName isn’t a condition to determine if application is or not full-trusted?

  2. I am not actually able to get what is it actually for ?

  3. Bypassing the strong name verification step during assembly load means that your assemblies will load much faster.  That, in turn, allows your managed application to have a quicker startup time.


  4. guillon says:


    by doing this you remove the integrity check of assemblies by default, don’t you?

    I can’t know if it is actually harmful at the end, but it seems to me that this was an important feature of .NET that is now left "aside". I.e. nobody except professional IT will ever re-activate it, letting most applications/machine without assembly integrity check.

    For instance I can just modify with a bin editor any byte of a dll signed assembly and it will be loaded as is, executing non expected code.

    Is there some reference justifying this apparently strange choice?

  5. That’s a good question guillon, and one I should write a whole blog entry on 🙂

    The basic point is that strong name signatures are not an integrity checking mechanism – they’re an assembly identity mechanism.  (They lack features of Authenticode signatures, such as chaining and revocation, which prevent them from being used as a full integrety checking mechainsm).

    That combined with the fact that full trust assemblies can easily fake their strong name(by design – full trust code owns the process), means that you weren’t getting an integrety check for free anyway.

    Instead, for integrety checking, you really need to use Authenticode signatures.


Comments are closed.

Skip to main content