Excel Add-in Deployment

[Ben Litchfield]

I have developed an Excel Add-in using VS2005, I have Excel 2003 on my
machine. It works as expected on my machine.

I created the an install package and tried to run it on a dev machine
without VS installed and using Excel XP. When I click the Automation button
I find my add-in in the list, I can add it and it is checks, no error
messages. But the add-in does not get loaded.

I checked the value of LoadBehavior and it changes from 3 to 2 when I open
excel, I tried changing it back to 3 but Excel keeps putting it back.

I have tried both with the shim and without with exactly the same results.

When I first installed it the regasm complained about the missing
Extensibility.dll, but I copied that over and now both my shim and add-in dll
appear to register successfully. How can I test what is wrong?

Any help is greatly appreciated,
Thanks,
Ben

 

[Cindy M -WordMVP-]

Hi =?Utf-8?B?QmVuIExpdGNoZmllbGQ=?=,

Have you tested deploying on a machine with Office 2003? Technically, if you
compile using the Excel 2003 DLL you shouldn't be installing on a non-2003
machine. It might work, but you should rule out this possibility first.

I have developed an Excel Add-in using VS2005, I have Excel 2003 on my
machine. It works as expected on my machine.

I created the an install package and tried to run it on a dev machine
without VS installed and using Excel XP. When I click the Automation button
I find my add-in in the list, I can add it and it is checks, no error
messages. But the add-in does not get loaded.

I checked the value of LoadBehavior and it changes from 3 to 2 when I open
excel, I tried changing it back to 3 but Excel keeps putting it back.

I have tried both with the shim and without with exactly the same results.

When I first installed it the regasm complained about the missing
Extensibility.dll, but I copied that over and now both my shim and add-in dll
appear to register successfully. How can I test what is wrong?

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or reply
in the newsgroup and not by e-mail

 

[Cindy M -WordMVP-]

Hi Ben,

Hmm, I thought it would still be compatible. I'll give it a try and see if I
can get it to work with 2003 on the non-dev machine. So, if I need to
support 2000+(2000/xp/2003) is that possible? Do I just compile against the
lowest version and then it will work for the future versions?

If you read the Microsoft documentation, it will tell you to compile a separate
Add-in for each version. What you definitely should not do is program against
the newest version - always program against the oldest version (= the lowest
common denominator) to avoid using functionality not available in an older
version. Plus...

You don't mention whether you used VB.NET or C#, and if VB.NET whether Option
Explicit On. But assuming C# or Option Explicit On, chances are the code can't
be compiled because a method signature has changed. For example, the
Workbooks.Open method requires a different number of parameters in different
versions of Excel.

The problem with a .NET implementation is that you're not programming directly
against the object libraries (as with a unmanaged COM Add-in), but against an
Interop Assembly. 2003 and 2002 (XP) have their own PRIMARY Interop Assemblies,
but only the ones for 2003 are part of the package. The ones for 2002 (Office
XP) have to be installed separately (available on msdn). Earlier versions of
Office have no PIAs; an IA has to be generated by Visual Studio (TblImp.exe is
the tool's name, as I recall) - which will happen when a reference is set to the
COM object.

If you're expecting your managed Add-in to work with Office 2000, then you need
to program against that version. That means installing it on a Dev (virtual)
machine, setting a reference to that COM library, and generating the
necessary IAs, that you then need to distribute as part of your solution. If you
do this, then the problem won't be the IAs, since the solution will run only
against the IAs you distribute, even if PIAs are available in the GAC.

The other possibility is to use late-binding throughout your code so that your
solution has absolutely no references to any of the Office libraries.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or reply
in the newsgroup and not by e-mail