How to deploy .NET Add-In using VS2003

[Joe Acunzo]

I've ported a VB6 COM Add-In to VB.NET using Visual Studio .NET 2003 (NOT 2005, don't have it, and without VSTO). It's working fine on my dev machine, but I cannot get it to load on a test machine. I've got all of the registry entries setup and used regasm on the necessary DLL's. Outlook 2003 reports there was an error in mscoree during the load when I look at the Add-In status. I read something about permissions, so I tried using caspol to change permissions on the folder containing the assemblies, but that didn't help.

What am I missing to deploy a .NET Add-In?

Joe A.

 

[Ken Slovak - [MVP - Outlook]]

Are you installing your pre-requisites and dependencies on the target
machines or checking for them (PIA's, Framework 1.1 or 2.0, etc.)?

 

[Joe Acunzo]

Framework 1.1 is installed, Microsoft.Office.Interop.Outlook.dll, office.dll and extensibility.dll all installed and regasm'ed (into a test directory).

Anything else I can check?

I look at the COM Add-Ins via Outlook 2003's GUI, and my Add-In is not checked (though I set the load behavior in the registry correctly, I think it failed to load so has this setting). So I check it, click OK, come back to that dialog, and it states "Location: mscoree.dll" and "Lead Behavior: Not loaded. A runtime error occurred during the loading of the COM Add-in."

However, I used a VBS script to help debug the problem, and there is no error reported doing this:

dim oApp
dim myObj
set oApp = CreateObject("Outlook.Application")
MsgBox(oApp.Version) ' displays 11.0.0.8010
Set myObj = oApp.COMAddIns.Item("SendToQuickBaseAddIn.Connect")
MsgBox(myObj) ' displays the default property, title/caption of the add-in

Thanks!
Joe A.

 

[Ken Slovak - [MVP - Outlook]]

Even if your addin is disabled that script will work. It's just reading all
the addins registered for Outlook, loaded or not.

Did you look in the \Windows\Assemblies folder to make sure the PIA's are
loaded there, same for any dependencies? For testing it's also OK to deploy
them all to the installation folder to see if things work then.

Usually that error, in an unshimmed shared addin, means a dependency isn't
available so the addin load failed.

 

[Joe Acunzo]

The PIAs seem to be there, but I downloaded and installed the "Office 2003 Update: Redistributable Primary Interop Assemblies" on this test machine to be sure something wasn't missing. However, in \Windows\Assembly there is no Extensibility.dll registered. So I regasm'ed the copy in my local folder (copied from my development machine). After doing this, it still fails the same way. Very frustrating.

I ran Depends on my DLL, and there are no missing dependencies.

I now understand that my VBS script didn't prove anything (i.e. didn't load my DLL), so how can I debug this issue? Is there a way to load my addin DLL the same way Outlook does so I can see if there is a complaint from the Windows loader about something missing? Is there something else I can check on that test machine? In each entry point in my addin, I put a MsgBox and then Exit to ensure it's not anything my code is doing, but from the error (and what you've said), I don't believe the DLL is ever loaded, so my code is never even called.

Thanks for your help!
Joe A.

 

[Ken Slovak - [MVP - Outlook]]

There's really no way for anyone but you to tell what's missing. What I'd do
in the same circumstances is to look at every reference in my addin project
and look at the deployed dependencies and see if anything's missing. Beyond
that I don't have a clue.

 

[Joe Acunzo]

Ken - I found the problem on my test machine! It was NOT a missing dependency, so I was barking up the wrong tree. Turns out the registry settings were not complete for the COM interface, not sure why. In the InprocServer32 section, the "Assembly" value specified a version (i.e. "TestAddIn, Version=1.0.3067.30742, Culture=neutral, PublicKeyToken=null"), but that version did NOT exist as a subsection in the registry. That is, there was no registry section named "1.0.3067.30742" under InprocServer32 as there should have been (and as there is on my development machine). I manually added that and it worked!

Shouldn't regasm have created that section for me, or must I do that "manually"? (I'm manually setting up the add-in on this test machine to determine what I must do in an NSIS installation script I've written to install my add-in. Again, I don't have any "deployment" tools to use as I'm using VS 2003.

Thanks,
Joe A.

 

[Ken Slovak - [MVP - Outlook]]

That I have no idea about. I use either Installshield or the VS installer
and in both cases I just set the addin dll for COM registration and that
takes care of all the nasty details of registering in HKCR. I have to set up
the registration for the addin in \Outlook\Addins of course, but the other
COM registrations are taken care of automatically.