G
Greg
I apologise for cross posting this in Microsoft.public.Excel (via google) but
I hope this is a more appropriate forum
We have many spreadsheets using a common (VB6) library developed and
maintained in house.
We rollout changes to this DLL by startup scripts which deregister
replace and re-register the DLL in C:\library which is common to all
workstations. We nearly always enforce BINARY COMPATIBILITY for
obvoius reasons.
We also use this library in VB6 and C# console and GUI applications.
These apps all work fine and recognise new library perfectly when we
rollout.
Yet EXCEL (2003 SP2) workbooks randomly (apparently) report MISSING DLL or
fail
executing methods of the DLL. This varies and is not consistent
across all workstations. When this occurs we de-reference and re-
reference the workbook in question and that solves the problem. It
has happened on the most trivial of DLL changes, for example when we
just changed a private variable to public. The GUID is always the
same.
We also have a workbook which scans all the network folders and
refreshes the reference on all spreadsheets which use the DLL. But
this is very kludgy and risky and we are reluctant to do things this
way.
How can we identify the Excel/Registry issue and either avoid the
problem altogether or anticipate which spreadsheets may be affected
and why? Has anybody managed to solve this issue?
What does Excel retain about the DLL that causes it to think the DLL
is missing?
What is different about Excel's handling of references compared with
the VB6 and C# apps?
Thank you for help..
I hope this is a more appropriate forum
We have many spreadsheets using a common (VB6) library developed and
maintained in house.
We rollout changes to this DLL by startup scripts which deregister
replace and re-register the DLL in C:\library which is common to all
workstations. We nearly always enforce BINARY COMPATIBILITY for
obvoius reasons.
We also use this library in VB6 and C# console and GUI applications.
These apps all work fine and recognise new library perfectly when we
rollout.
Yet EXCEL (2003 SP2) workbooks randomly (apparently) report MISSING DLL or
fail
executing methods of the DLL. This varies and is not consistent
across all workstations. When this occurs we de-reference and re-
reference the workbook in question and that solves the problem. It
has happened on the most trivial of DLL changes, for example when we
just changed a private variable to public. The GUID is always the
same.
We also have a workbook which scans all the network folders and
refreshes the reference on all spreadsheets which use the DLL. But
this is very kludgy and risky and we are reluctant to do things this
way.
How can we identify the Excel/Registry issue and either avoid the
problem altogether or anticipate which spreadsheets may be affected
and why? Has anybody managed to solve this issue?
What does Excel retain about the DLL that causes it to think the DLL
is missing?
What is different about Excel's handling of references compared with
the VB6 and C# apps?
Thank you for help..