Lazy add-ins

VSTO add-ins some times  irritates us by causing delay. No work around works for it and atleast a clue will not be available for us to work on that. It works fine in some systems. It loads slowly in some other systems. Some times, it even does not load in some systems.  30 second dealy, slow start-up, checking for certificate, publishing problems etc. comes under this domain.

Forums are the best places to get solutions to this kind of problems. Ofcourse, obviously almost every programmer will be going through Forums, especially VSTO programmers.

These are the links from forums for those who are sufffering from lazy add-ins (loading slowly) problem. These are the dicsussions on the delay problem. Hope this helps!

Slow Outlook startup

30 second start up delay

Performance problems for network profiles

Slow start-up time

A very technical (related link)


Another work around for slow loading of vsto add-ins


Just came across another work-around for slow loading of add-in.

Add app.config file to your add-in and write the following code in it.



<generatePublisherEvidence enabled=”false”/>



Please refer to this article: FIX from MSDN

Performance issues in add-ins


Most of the VSTO developers suffer with ‘first time load performance’ problem. Beyond the “normal” performance tuning that one can do to code, one can try to put the add-in into the Zap cache using NGEN. Here is a link to an excellent MSDN article that discusses the subject of NGEN and .Net applications.


How to: Improve Performance

Why add-ins load slowly?

Hi all,

This question pestered my mind for so many days.

I have developed an add-in. It is working fine but taking much time to load. After studying all the issues related to it, I came to know that the add-in is connecting to and every time I open the application (my add-in loads at start-up). This problem comes up with self-signed certificates. It will check the exitence of  self-certificate in Certificate Revocation List.

There are some work-arounds for solving this problem.

This behavior will occur with any .NET 1.1 and 2.0 assembly that is authenticode-signed, not only Measurement Studio assemblies. Digital signing is also referred to as code signing. Code signing a .NET library is strongly recommended by Microsoft, and Measurement Studio signs all of our ActiveX and .NET components.

Code signing of assemblies makes components tamper-proof and ensures that you know the identity of the component publisher.

The reason why this problem is occurring is because of the mechanism used by the .NET Common Language Runtime (CLR) to verify code-signed .NET assemblies. Part of the verification process requires an online look-up to check whether the certificate with which the assembly is signed has been revoked and is no longer valid. Windows does this by downloading a CRL (Certificate Revocation List). The first time a code-signed assembly is loaded by the .NET CLR, the CRL is downloaded from the certificate provider’s server and cached on the system.

When the .NET CLR loads a code-signed assembly and is unable to reach the CRL distribution point, it records the failure as an inability to provide the assembly evidence that it was code-signed. So the assembly is allowed to load, but is not marked as being digitally signed. There is a 15 second delay for CRL retrievals. This is how long the CLR will keep on re-trying to download the CRL before it finally times out. So the delay in loading the .NET assembly occurs because Windows is unable to download the CRL and keeps trying to download it for 15 seconds before timing out.

This behavior is by design.

The .NET CLR will not indicate any error or throw any security exception when verifying a signed assembly if the CRL distribution point cannot be reached. An error here from WinVerifyTrust(), the API used by the .NET CLR to verify a code signed assembly, prevents the assembly from being marked as code signed. Note that this does not apply to assemblies loaded thru the Internet Explorer hosting interface.

You could manually download the CRL and install it on your system. But the CRL is valid only for 10-15 days, so unless your system is able to update the file after this time, you will run into the same problem again.

Microsoft recommends disabling CRL checking as a workaround by disabling this option in Internet Explorer. Use the following steps to disable the CRL checking in Internet Explorer:

  1. Select Start»Control Panel.
  2. Double-click Internet Options.
  3. Select the Advanced tab.
  4. In the Security section, uncheck the Check for publisher’s certificate revocation option.

By disabling the CRL checking using the Internet Options, you are not exposing yourself to a security threat because this check is not working. The reason why this problem is showing up is because your network settings are not allowing Windows to access the CRL.

In addition, it is possible to programmatically set the CRL verification. When the Check for publisher’s certificate revocation is unchecked, a setting in the registry is changed.

To turn off CRL verification, set HKCU\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State from 0x00023c00 to 0x00023e00.

To turn CRL Checking on again, reset the State key to 0x00023c00"

Another work-around is to select the ‘Never search for updates’ option in Add-In Properties->Publish->Updates.

So by unchecking the above mentioned option in Internet Explorer and disabling the search for updates in Visual Studio, the problem will be solved.

What is Marshalling?

Marshaling is the act of taking data from the environment you are in and exporting it to another environment. In the context of .NET, marhsaling refers to moving data outside of the app-domain you are in, somewhere else.

When you work with unmanaged code, you are marshaling data from your managed app-domain to the unmanaged realm. Also, when transferring data between app-domains (to another application, on the same or another machine), you are also marshaling data from your app-domain, to another app-domain.

Unmanaged code is simply all code pre .NET. It is all code NOT compiled to operate under .NET’s runtime, the CLR. Unmanaged code is code compiled and linked natively and has no knowledge of the CLR. Unmanaged code can be
native C++ with pointers, or C, or VB 6, or Delphi, etc. It is everything not managed by the CLR. In the CLR, code is compiled into IL + metadata into assemblies and then those assemblies are JITed into assembly language
instructions while called. It is the metadata throughout that allows managed code to be managed, managed by the CLR. The CLR can control the type definitions and boundaries (enforce CTS type definitions), control memory
through automatic management of data via the garbage collector, and provide CAS security among other benefits. So a class is managed code IF compiled with a .NET compiler and controlled by the CLR whereas “other code is
unmanaged” because it is compiled without a .NET compiler and uses the unmanaged heap for memory and knows nothing of the CLR.

Essentially, both systems produce a Windows PE format file in the form of a DLL or EXE. The huge difference is that in .NET, that PE file is called an assembly and has different header. It also contains IL + metadata. All .NET compilers are REQUIRED to emit IL + metadata. The metadata fully describes all types in terms of CTS types. The metadata allows managed code to be called “self-describing.” When that assembly is loaded, and the types used, the CLR JIT’s the IL for the called method and replaces that section of IL with the native assembly language. The IL is *never* interpreted but provides a common platform-independent, language-independent standard form. Because of all this, the CLR can manage the types and provide it’s services.