Installing C# Add-In in InstallShield not working. (FAQ?)

[Mike Edenfield]

We have a C# Word/Outlook/Excel add-in that we cannot get to install
properly. The component is part of a much larger InstallShield
MSI-based setup, and although installshield appears to be doing
everything properly, the add-in never loads.

The odd part is that, if we make just a simple VS.NE setup project for
the add-in, and run that, it works fine. But I can't see any difference
between the two setups. Here is what we do:

1) Copy the add-in DLL plus all of it's assemblies into the runtime
folder. We are including the PIA for Office, including:

Microsoft.Office.Interop.Excel.dll
Microsoft.Office.Interop.Word.dll
Microsoft.Office.Interop.Outlook.dll
Office.dll
Extensibility.dll
Interop.MAPI.Dll
Microsoft.Vbe.Interop.dll

I have read a number of replies that this is a bad idea; however, I
don't see any way to avoid doing so. Most of the Office machines we
have in this office don't have these assemblies installed, so I suspect
a number of our clients also won't have them. This setup works if we
use the VS.NET setup project, so I can't see how it would be the cause
of our problems.

2) Run regasm on the installed Interop assembly:

regasm Company.OfficeConnector.dll /codebase /tlb

3) Add the Add-In to the Office registry locations:

HLKM\Software\Microsoft\Office\{Excel|Word|Outlook}\Addins:
CompanyOfficeConnector.Connect
Description="Whatever"
FriendlyName="Company.OfficeConnector"
LoadBehavior=0x00000003


As far as we can tell, this is all the VS.NET setup does, and our
InstallShield setup mimics this. However, one works and one doesn't, so
clearly we're missing something. I have run filemon/regmon on
WINWORD.EXE and it does locate the add-in, load mscoree.dll, which then
loads our DLL from the installed location, but never gets any further
then that.

This appears to be a FAQ but I couldn't find any specific information on
what troubleshooting steps to take, other than a couple of good
suggestions that we've already taken: we have exactly one COM-visible
public class that no internal classes as parameters, we have a lot of
error handling around the actual button creation on the toolbar, etc.

Any help would be greatly appreciated.

--Mike Edenfield
KutuluWare Software Services
(e-mail address removed) <be positive to contact>

 

[Mike Edenfield]

1) Copy the add-in DLL plus all of it's assemblies into the runtime
folder. We are including the PIA for Office, including:

Microsoft.Office.Interop.Excel.dll
Microsoft.Office.Interop.Word.dll
Microsoft.Office.Interop.Outlook.dll
Office.dll
Extensibility.dll
Interop.MAPI.Dll
Microsoft.Vbe.Interop.dll

I have read a number of replies that this is a bad idea; however, I
don't see any way to avoid doing so. Most of the Office machines we
have in this office don't have these assemblies installed, so I suspect
a number of our clients also won't have them. This setup works if we
use the VS.NET setup project, so I can't see how it would be the cause
of our problems.

Ok, after reading about a dozen articles and posts explaining why this
doesn't work, I have resolved that we're going to have to force the user
to deal with this problem. We are now using the copies of these
assemblies from the GAC, and are not shipping them with our setup
(except for extensibility.dll).

This appears to work, *if* the end-user has Word, Outlook, and Excel
installed. (We use the same plug-in for all three applications). None
of our test machines had Excel installed since we had no need to use it.
Unfortunately, the Excel PIA was neither installer nor advertised, so
the plug-in fails to load at all. Is there some way to just load the
Interop assemblies (via Office Setup or some other means) without having
the whole application installed?

--Mike