Slow .NET Assembly Load Times on Machines without Internet Access

The .NET assemblies (e.g., nsoftware.IPWorks.dll) are strong-named, and are also signed with an Authenticode certificate. When an Authenticode signature is verified, Windows checks whether the signing certificate has been revoked by contacting the Certificate Revocation List (CRL) and OCSP servers listed in the certificate. On a machine that cannot reach the internet (e.g., a server behind a firewall that blocks outgoing traffic), these requests do not fail right away, but time out, which can delay the loading of the assembly by several seconds or more. The delay usually appears as a slow first use of a component, or as a slow application or service startup.

The verification is performed by the .NET Framework runtime or by other software on the machine, not by the assembly itself, so it cannot be changed in the components.

.NET Framework Applications

In .NET Framework applications, the runtime verifies the Authenticode signature of an assembly when it is loaded, to create Publisher evidence for Code Access Security (CAS). Most applications do not use Publisher evidence, so this verification can be turned off by adding the generatePublisherEvidence element to the configuration file of the application (e.g., MyApp.exe.config, or web.config for ASP.NET applications):

<configuration>
  <runtime>
    <generatePublisherEvidence enabled="false"/>
  </runtime>
</configuration>

Microsoft recommends this setting for Windows services in particular, since a long delay at startup can cause the service to time out and fail to start. For more information, please see Microsoft's generatePublisherEvidence element documentation.

Strong-name signatures do not cause this delay, since they do not involve certificates, and the .NET Framework does not validate them when an assembly is loaded into a full-trust application (the strong-name bypass feature).

.NET Applications

In .NET (formerly .NET Core) applications, the runtime does not verify Authenticode or strong-name signatures when it loads an assembly, so the runtime does not cause this delay.

Other Causes

Anti-virus and other endpoint security software may also verify the signatures of files as they are loaded, and perform the same revocation checks. When a delay occurs in a .NET application, or remains after the configuration change above, this software is the most likely cause.

To avoid the delay in any application, allow the machine to reach the revocation servers of the signing certificate. The CRL and OCSP addresses can be found on the Details tab of the certificate, in the CRL Distribution Points and Authority Information Access fields (open the properties of the DLL in Windows Explorer, select the Digital Signatures tab, and click Details and then View Certificate). Alternatively, consult the documentation of the security software for options that control revocation checks.