 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / COM / September 2007Binary Compatible DLL causes Missing or Invalid Reference in Excel
I apologise for cross posting this from Microsoft.public. Excel but hope I may find an answer here, having no answers from the Excel community. We have many spreadsheets using a common (VB6 SP5) library developed and maintained in house; the library has about 30 classes. 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 obvious reasons. We also use this library in VB6 and C# console and GUI applications. These apps all work fine and recognise the 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 in 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 in a single class. The GUID is always the same for the DLL and all its classes. 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 your help..  Signature老鬼 LaoGui > <snipped> "It has happened on the most trivial of DLL changes, for example when we just changed a private variable to public in a single class." Don't know for sure what is happening, but the above might be part of the problem, because changing a private to a public variable IS NOT a trivial change. One often gets away with it, because one can add a procedure to an interface and not break the hierarchy of IDs. Type or Lib ID Interface ID ProcID *** But it can muck things up if one changes its location in the source file. VB assigns ProcIDs according to order. > The GUID is > always the > same for the DLL and all its classes. But not ProcIDs unless you maintain rigorous binary compatibility. > <snipped> -ralph Thank you for your reply... Yes, we try to preserve strict compatibility The fact that other client applications see the DLL seamlessly and that ALL the registry entries seem to preserve the same GUID and MOST excel workbooks have no problem is some kind of confirmation; but still a few workbooks fall over; only Excel is an issue I would love to understand how Excel know that the DLL has changed. Signature老鬼 LaoGui > > <snipped> > "It has happened on the most trivial of DLL changes, for example when we [quoted text clipped - 22 lines] > > -ralph > Thank you for your reply... > Yes, we try to preserve strict compatibility [quoted text clipped - 4 lines] > > I would love to understand how Excel know that the DLL has changed. I don't know either. The problem is that while from a certain level of abstraction COM is simple and universal - there are only a couple of ways to dereference an interface (late, early, blah, blah.), but I have found that on occasion MS takes a few "shortcuts" with OLE internals. <g> I wish you luck. If you ever solve it please come back and let us know what you discovered. -ralph |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.