Aniruddha
2008-03-10 07:00:00 UTC
We are developing an Excel add-in for our client. We are using Shared add-in
developed in .Net 2.0 using the Extensibility API and Add-in Express (third
party RAD API for office add-ins). We also have created a MSI installer,
which installed the add-in with necessary pre-requisites and environment.
Our add-in needs to be installed on investment analyst desktops, typically
in Mutual fund houses etc. They will have other add-ins installed most of the
times. Other competitors add-ins particularly. Some of this add-ins have bit
aggressive behavior and seem to control the Excel environment (particularly
the sequence of loading add-ins, the OPEN keys etc.)
Following are some of the observations.
1. Sometimes our add-in does not load even if the required OPEN key is
present and none of the preceding add-in causing any error
2. Sometimes the install fails to create the OPEN key (this is typically
seen when the other add-in out of process component is active)
3. We have some initialization code in the COM add-in part of our add-in,
where we try to create required OPEN key, the API returns without any error
but does not create the required keys also. Thus our UDFs can not get loaded.
4. Strange thing is if we manually disable all add-ins (using the disable
add-in function provided by most of the other add-ins) and one by one
re-initialize all of them keeping our add-in first, then every thing works
fine, but this sequence of OPEN keys created is automatically disturbed by
the other add-ins as they seem to be re-writing the OPEN keys every time they
load on Excel start-up.
Questions:
1. When our add-in OPEN key is present and it still does not load, how can
we determine what the problem is? What could be the cause? Is there a way to
log/debug Excel startup? As I understand even if one of the enabled add-in
fails Excel does try to load all listed/enabled add-ins but this does not
seem to work.
2. Should we create an out of process component which keeps monitoring and
re-writing OPEN keys all the time
3. Is there a deterministic way of handling OPEN keys such that the
conflicts don't occur or are reported properly?
4. Are there any other Excel start-up hooks which can be potentially used to
debug/control behavior of other aggressive add-ins which the other add-ins
might be already using?
~Aniruddha
developed in .Net 2.0 using the Extensibility API and Add-in Express (third
party RAD API for office add-ins). We also have created a MSI installer,
which installed the add-in with necessary pre-requisites and environment.
Our add-in needs to be installed on investment analyst desktops, typically
in Mutual fund houses etc. They will have other add-ins installed most of the
times. Other competitors add-ins particularly. Some of this add-ins have bit
aggressive behavior and seem to control the Excel environment (particularly
the sequence of loading add-ins, the OPEN keys etc.)
Following are some of the observations.
1. Sometimes our add-in does not load even if the required OPEN key is
present and none of the preceding add-in causing any error
2. Sometimes the install fails to create the OPEN key (this is typically
seen when the other add-in out of process component is active)
3. We have some initialization code in the COM add-in part of our add-in,
where we try to create required OPEN key, the API returns without any error
but does not create the required keys also. Thus our UDFs can not get loaded.
4. Strange thing is if we manually disable all add-ins (using the disable
add-in function provided by most of the other add-ins) and one by one
re-initialize all of them keeping our add-in first, then every thing works
fine, but this sequence of OPEN keys created is automatically disturbed by
the other add-ins as they seem to be re-writing the OPEN keys every time they
load on Excel start-up.
Questions:
1. When our add-in OPEN key is present and it still does not load, how can
we determine what the problem is? What could be the cause? Is there a way to
log/debug Excel startup? As I understand even if one of the enabled add-in
fails Excel does try to load all listed/enabled add-ins but this does not
seem to work.
2. Should we create an out of process component which keeps monitoring and
re-writing OPEN keys all the time
3. Is there a deterministic way of handling OPEN keys such that the
conflicts don't occur or are reported properly?
4. Are there any other Excel start-up hooks which can be potentially used to
debug/control behavior of other aggressive add-ins which the other add-ins
might be already using?
~Aniruddha