MidniteBlog

So far we have created an Add-in for Outlook with the Visual Studio wizard.  If you missed that, you can go back to Part 1. 

Go ahead and build it and make sure there is no problem there.  If all is well, you should have a bin\Debug directory underneath your MyAddin directory and a MyAddin.dll in it.  If not, you probably set something up wrong.  Try it again from the start. 

By default, building with Visual Studio will make the Add-in available from Outlook.  (For this example, I am using Outlook 2003, but other versions are similar).  Just to make sure all is well, after you have built MyAddin, open up Outlook (close and reopen it if it was already open) and choose Tools/Options…  menu item. 

In the ensuing dialog, go to the “Other” tab, “Advanced Options…” button.  This brings up another dialog.  Choose the “COM Add-Ins…” button from here which brings up yet another dialog which should be titled something like “COM Add-Ins.” 

If all is OK to this point, your shiny new Outlook Add-in should show up in the “Add-Ins available” check list box.  It should also be checked (check it if it is not).  If your Add-in did not show up, something probably went wrong with the build.  I would suggest starting over with the wizard process in Step 1. 

Note also that when you highlight your Add-in, the “Location” text at the bottom of the dialog should indicate “mscoree.dll.”  This is the .NET runtime .dll.  Why is mscoree.dll there instead of MyAddin.dll?  What this means is that Outlook is going to load mscoree.dll which will load MyAddin.dll.   Through a bit of registry hocus pocus, .NET basically lies to Outlook and gets it to load .NET first instead of MyAddin.dll.

We will come back to this topic later and discuss why it may not be a good idea to let Outlook do this, and some ways to get around it.

Before we leave the “COM Add-ins” dialog, make sure the “Load Behavior” label says “Load at Startup.”  If not you did something wrong in the wizard set-up.

So where we are now is that when Outlook starts up, it will load your MyAddin.dll (through mscoree.dll) and start talking to it through interop (remember, Outlook is still COM based).  How does it talk to your Add-in?  Through the IDTExtensibility2 interface we learned about in Part 1 of our discussion. 

If you are interested in the timing of the loading, you can put a Message Box in OnConnection ( ) and see that your Add-in is loaded just as Outlook is coming up.   (You will have to add a reference to System.Windows.Forms to be able to show a MessageBox)

Before we get on to customizing Outlook, let’s note one further item that has been created for us by Visual Studio.  Look at your project Solution Explorer and there should be a “MyAddinSetup” project there.  If you right click on it and choose “Build,” it will create a setup .msi under the “MyAddinSetup” directory that you can use to install your Outlook Add-in on other machines. 

This comes in very handy when it comes time to redistribute your Add-in.  Also, if you right click on the MyAddinSetup project and choose “Properties,” a property page will come up that will allow you to specify Prerequisites for your install.  Click on the “Prerequisites” button and in the ensuing dialog, you can specify what your project needs in order to run.  Make sure the .NET framework is selected here.  Remember, however, that this install will tie your Add-in specifically to mscoree.dll as its Outlook loader.  As noted above, this is not always a good idea.  More about this later. 

In Part 3, as promised, we will begin customizing Outlook.  Stay tuned…