A
Anthony Berglas
Hello All,
The way add-ins are installed seems to have changed radically from the
Beta to the final release of Excel 2010.
I have an ordinary VBA Add In, and have for many version of Excel used
a simple installer that sets
HKCU\software\microsoft\office\14.0\excel\Options:OPENn
to the .xlam file that is the add in. (If more than one add-in is
installed then the keys are listed as OPEN1, OPEN2...) The .xlam file
itslef is stored by default in an arbitrary folder, not an addins
folder.
This worked in the beta.
But in the production version, setting this key makes no difference.
I can install the add-in perfectly via the UI, but then a full search
of the registry fails to find any key that points to the add-in.
Moving the add-in files causes Excel to complain, so something is
definitely pointing to them.
(I have tried to use Sysinternals Procmon, but Excel does so much that
it will take time to filter the results. 100s of events per second
when Excel is just sitting there! During an add in install it opens
the add in file dozens of times.)
Any ideas as to what happened would be greatly appreciated. Many
people will have this problem.
A work around is to install the files in the %APPDATA%\Microsoft
\AddIns folder. Make the .xlam the top level. (In my case I also
have a .xla file for older versions of Excel, but that must *not* be
in the AddIns folder or XL 2010 prefers it over the .xlam and
complains.) Then the addin appears in the list, but still needs to be
manually enabled. The add ins list is hard for some users to find,
being four clicks from the top.
Anthony
The way add-ins are installed seems to have changed radically from the
Beta to the final release of Excel 2010.
I have an ordinary VBA Add In, and have for many version of Excel used
a simple installer that sets
HKCU\software\microsoft\office\14.0\excel\Options:OPENn
to the .xlam file that is the add in. (If more than one add-in is
installed then the keys are listed as OPEN1, OPEN2...) The .xlam file
itslef is stored by default in an arbitrary folder, not an addins
folder.
This worked in the beta.
But in the production version, setting this key makes no difference.
I can install the add-in perfectly via the UI, but then a full search
of the registry fails to find any key that points to the add-in.
Moving the add-in files causes Excel to complain, so something is
definitely pointing to them.
(I have tried to use Sysinternals Procmon, but Excel does so much that
it will take time to filter the results. 100s of events per second
when Excel is just sitting there! During an add in install it opens
the add in file dozens of times.)
Any ideas as to what happened would be greatly appreciated. Many
people will have this problem.
A work around is to install the files in the %APPDATA%\Microsoft
\AddIns folder. Make the .xlam the top level. (In my case I also
have a .xla file for older versions of Excel, but that must *not* be
in the AddIns folder or XL 2010 prefers it over the .xlam and
complains.) Then the addin appears in the list, but still needs to be
manually enabled. The add ins list is hard for some users to find,
being four clicks from the top.
Anthony