Slow Excel Start Up After Installing Add-In

[Ross Del Busso]

Hello,

After installing an Add-In created by the VS 2005 Shared Add-In template,
Excel takes 15 seconds to start. I've done conserable diagnosis on this and
found that the problem can be recreated by generating an "empty" Shared
Add-In project and add the following lines:

Private itsExcelApplication as Microsoft.Office.Interop.Excel.Application '
as a class varaible

itsExcelApplication = DirectCast(application,
Microsoft.Office.Interop.Excel.Application ' in the OnConnection function.

The first Excel start after logon takes 15 seconds. Subsequent Excel starts
take anywhere from 2 to 15 seconds depending on how long it has been since
the last Excel startup. I have read many posts about com add-ins being
slow, but 15 seconds is a show stopper! Is there any way to speed this up?

Thanks.

Ross

 

[Ross Del Busso]

Dennis,

Thanks for the answer.

Yes, it is Excel 2003 and I have the PIA's installed (via the appropriate
..NET features in Office and Excel 2003).

I started to look at the shim yesterday but could not get the sample to
work, I don't fully understand what the shim does. I'll be looking at it
again today. Do you think the shim will improve the startup time?

I am aware of only 2 methods to change the load behavior: manually edit the
registry which is not an option as we are developing the addin for
commercial use; or building an xll "front-end" to the .NET stuff with the
Excel C API. I HAVE been experimenting with that but found that the same 15
second delay is experienced when transitioning from the xll code to the .NET
code confirming that the CLR is the culprit.

Ross

 

[Ross Del Busso]

All this time I did not know there was a COM Add-Ins dialog in Excel! Why
is it buried?

The shim did not improve startup, but now I do see the Add-In in the COM
Add-Ins dialog. Why doesn't an un-shimmed add-in appear?

 

[Ross Del Busso]

Actually I found out why my add-in wasn't listed: I was installing it under
the LOCAL_MACHINE registry key. Putting it under the CURRENT_USER caused it
to be listed. That makes sense in that it prevents a single user from
affecting all users of the machine I guess.