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 crl.microsoft.com and downlaod.microsoft.com 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 HKCUSoftwareMicrosoftWindowsCurrentVersionWinTrustTrust ProvidersSoftware PublishingState 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.

Professional Outlook 2007 Programming

Outlook ebook

Professional Outlook 2007 Programming

Written by one of the most popular and knowledgeable Microsoft Outlook MVPs, this book emphasizes the many new and exciting Outlook 2007 programming features. Ken Slovak shows you all you need to know to develop everything from Outlook custom forms and personal productivity macros to advanced COM add-ins that use a range of Microsoft technologies.

The Outlook 2007 model fulfills many of the requests that Outlook developers have been making for years. You’ll see how many of the programming properties that are considered vital, but were previously unavailable in older versions of Outlook, now exist. Real-world examples show you how to solve common Outlook programming problems. Plus, you’ll learn common workarounds for Outlook programming bugs. You’ll quickly discover why you’ll rarely if ever have to leave the Outlook object model to do what you want with your code when using Outlook 2007.

Download Here

Shim

Shim is a generic term for any piece of code, usually in a DLL, that acts as an intermediary between two incompatible systems.  A typical use for a shim is to make an unmanaged DLL usable to a .NET program.  It would present a managed class interface to the .NET project and translate managed method calls to native method calls, marshaling the method arguments as needed.
The shim on .NET is the mscoree.dll and is the responsible to assign you the correct .NET version when you host the CLR.

Multiple Projects in one Solution in visual studio 2008

Every time I attempted to create a single solution in Visual Studio 2008 with multiple projects, the Solution icon in the Solutions window disappeared after adding the first project. That resulted in my not being able to add additional projects by right clicking the top level solution icon. You can fix that easily by clicking Tools –> Options –> “Projects and Solutions” General property page and checking “Always show solution“. I am not sure why the default was unchecked, but it was. I hope this tip helps people that might be confused by this behavior.

Uploading a file to server using FTPWebRequest

Here is the code for uploading files to a particular system(or a server) using FTP.
FtpWebRequest ftpRequest;
FtpWebResponse ftpResponse;
try
{
//Settings required to establish a connection with the server
this.ftpRequest = (FtpWebRequest)FtpWebRequest.Create(new Uri(“ftp://ServerIP/FileName“));
this.ftpRequest.Method = WebRequestMethods.Ftp.UploadFile;
this.ftpRequest.Proxy = null;
this.ftpRequest.UseBinary = true;
this.ftpRequest.Credentials = new NetworkCredential(“UserName”, “Password”);
//Selection of file to be uploaded
FileInfo ff = new FileInfo(“File Local Path With File Name”);//e.g.: c:\Test.txt
byte[] fileContents = new byte[ff.Length];
using (FileStream fr = ff.OpenRead()) //will destroy the object immediately after being used
{
fr.Read(fileContents, 0, Convert.ToInt32(ff.Length));
}
using (Stream writer = ftpRequest.GetRequestStream())
{
writer.Write(fileContents, 0, fileContents.Length);
}
this.ftpResponse = (FtpWebResponse)this.ftpRequest.GetResponse(); //Gets the FtpWebResponse of the uploading operation
Response.Write(this.ftpResponse.StatusDescription); //Display response
}
catch (WebException webex)
{
this.Message = webex.ToString();
}

Architecture of VSTO Add-In

add-in-architecture

The main design considerations of Office Application-Level Add-In Architecture are following:

  • Each add-in is loaded in new application domain so as to isolate it from main app and other add-ins. Thus if the add-in hangs whole app doesn’t crashes.
  • Security and Permission level checks performed on add-ins.
  • Clean shutdown of application and loaded add-ins.

The main components which take part in functioning of Application-Level Add-Ins are following:

Architecture Components

Runtime Loader

The component is named VSTOEE.dll and is responsible for loading the correct version of VSTO runtime when a document-level customization is opened or add-in is started.

Solution Loader

It is named VSTOLoader.dll. This is responsible forloading the VSTO application. It also creates a new Application Domain for eachadd-in and performs security checks on VSTO application.

Registry Entry

This is where the Office application discovers the add-ins installed and to be loaded.
Applications in the 2007 Microsoft Office system look for the Manifest entry under the key HKEY_CURRENT_USERSoftwareMicrosoftOfficeapplication nameAddinsadd-in ID(or, for Visio, HKEY_CURRENT_USERSoftwareMicrosoftVisioAddinsadd-in ID).
The Manifest entry specifies the full path of the deployment manifest.

Deployment Manifest and Application Manifest

The list of Deployment manifest indicates the add-ins installed. Each deployment manifest points to the correct version of an application manifest which in turn points to assembly paths and entry points.

Add-In Loading Process

  1. The Office Client application checks the registry installed add-ins.
  2. It loads Runtime Loader which in turn loads Solution Loader.
  3. SolutionLoader loads the .NET Runtime and managed portion of VSTO Runtime.
  4. Latest versions of Deployment and Application manifests are downloaded. Once security checks are passed, latest add-in assemblies are downloaded.
  5. New application domains are created for each add-in and add-ins are loaded into that app domain.
  6. Various entry point methods of Add-in are called before finally calling ThisAddIn_Startup method which is default event handler for Startup event.

(Text quoted from http://bit.ly/cGul3q)

architecture-of-outlook-add-in