 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / COM / February 2008Questions about COM
I have spent about a week trying to debug a frustrating software bug. I've finally discovered that the bug is caused because some computers are using an incorrect version of a required COM component. I've put the correct version of the DLL on the computer, but whenever the incorrect version exists, the system always chooses to use it instead. How does the system choose which version of a DLL to use, and how can I redirect it? Working on this problem, I've come to realize there is a lot I don't know about using COM components. When I register a COM component, am I saving a pointer to a specific file? If not, how does the system find the file that corresponds to a registered COM component? -TC > I have spent about a week trying to debug a frustrating software bug. > I've finally discovered that the bug is caused because some computers [quoted text clipped - 11 lines] > > -TC Time to get a good book. <g> I recommend Matt Curland's "Advance VB Programming" or any of the COM basics for beginner books. But one of the quickest ways is to just open up the Registry and take a peek. http://support.microsoft.com/kb/q183771/. As for your specific example, there isn't enough information. Usually placing a new component that supports the same Interface on a target platform and registering it does the trick. But there are some Gotchas. One, it is possible that an App is calling a component with a specific versioned ProgID, and the ProgID.Version registry entry doesn't point to the new component. Two, you might be fighting Windows File Protection (WFP). This comes about when a component is listed as a 'protected component' in a system folder like System32. Windows will accept the new registration, etc. and then quietly put everything back again. Three, perhaps this component is part of a chain of dependancies, you have isolated the component the Program is complaining about - but it is actually others that are equally mismatched. ie, you might need to update an entire suite of components. Four, what are you doing with the original component? Try un-registering and then renaming it. This is not an all inclusive list. Perhaps if you could provide more information. -ralph > > I have spent about a week trying to debug a frustrating software bug. > > I've finally discovered that the bug is caused because some computers [quoted text clipped - 45 lines] > > -ralph Ralph, Thank you for the advice. I now have a clearer picture of what is happening, and can provide a better description of my problem: I have two different versions of a COM DLL. The newer version has a bug which causes my application to fail. The newer version is installed on the production computer because it has features some software requires. Therefore, I can't uninstall it or mess with its registration. My question is: How can I instruct my software to use the older version of the COM DLL, without messing with the newer version? If I register the older DLL, will that invalidate the registration of the newer DLL? Is there some way in code to ignore the registry and explicitly reference a specific version of a DLL? -TC My question is: How can I instruct my software to use the older version of the COM DLL, without messing with the newer version? If I register the older DLL, will that invalidate the registration of the newer DLL? Is there some way in code to ignore the registry and explicitly reference a specific version of a DLL? ---------------------------- Correct. Re-registering the older DLL will overwrite the registry settings. However, you need to restart any applications that are currently holding on to the previous (newer COM object). Of course, I'm assuming that you have observed the COM rules of interface immutability and haven't added or subtracted any methods between these two versions.... Brian > I have two different versions of a COM DLL. The newer version has a > bug which causes my application to fail. The newer version is [quoted text clipped - 7 lines] > newer DLL? Is there some way in code to ignore the registry and > explicitly reference a specific version of a DLL? Why? Why not rewrite your code to overcome the problem, and then include the newer version as part of your installation? If it really is the newer version of some other org's DLL, then there's not much you can do to prevent it getting installed after whatever steps you might take. Personally, I think I would be encouraged to get rid of that dependency altogether, considering that whoever updated it has "broken it before" ... the only alternative explanation I can come up with is that your code relies on bugs that have since been fixed. Either way, you're better off getting rid of the old one, if not getting entirely away from both. Bob -- > I have two different versions of a COM DLL. > The newer version has a bug which causes my [quoted text clipped - 3 lines] > Therefore, I can't uninstall it or mess with its > registration. You can use my DirectCOM.dll to achieve what you need. This small Standard-Dll offers a GETINSTANCE()- Call, which can instantiate classes from your older COM-Dll without the need to register that Dll (simply place both, DirectCOM.dll and your OldCOMVersion.dll in your App.Path, beside your Exe). Then on your Developer-Machine you should keep the reference to your older Dll in your VB-Project. Then you can replace e.g: Dim oMyObj as cMyDllClass Set oMyObj = New cMyDllClass with: Dim oMyObj as cMyDllClass Set oMyObj = GEINSTANCE(App.Path & "\MyOlder.dll", _ "cMyDllClass") You would have to replace all occurences of 'New' or CreateObject-based instantiation inside your Code with those GetInstance-Calls (for Classes of your older COM-Dll). This works earlybound against your older interfaces (which is compiled into your App on your Dev-PC) without using the registry in your production-environment. And that means, the new Dll can sit there and is usable from other Apps - but your App is using your older Dll directly from the FileSystem (your App.Path). DirectCOM.dll is included in my dhRichClient-Demo: www.datenhaus.de/Downloads/dhRichClientDemo.zip Olaf |
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.