Help on vb6 and .dll
-
windows XP, vb6 My vb6 project requires to reference A.dll in order to run properly. In my PC, the compiled .exe program runs normally. BUT when i deployed it to another computer, it does not run normally. UNTIL I realised i have to register the dll on that computer. I did not realize it had to do with registering the dll because I did not register the dll on my PC before. It seems that when I compile my project, vb6 automatically registers A.dll. Therefore it ran nomally on my PC. Therefore, I have coded my program to auto-register the A.dll itself. And I tested on my PC, it was ok. But again when I deployed to another PC, it doesn't work. QUESTION: Even after I unregistered the A.dll on my PC, I still can run my program normally! For some reason, vb6 keeps locking on to my dll. and I cant seem to unregister it. Therefore I am unable to test my auto-registering code! How can I unregister the A.dll on my PC, so that I can test out the auto-registering of the A.dll itself?? I would prefer to perform the testing on my PC than to deploy it over and over again to find out if my code works.
-
windows XP, vb6 My vb6 project requires to reference A.dll in order to run properly. In my PC, the compiled .exe program runs normally. BUT when i deployed it to another computer, it does not run normally. UNTIL I realised i have to register the dll on that computer. I did not realize it had to do with registering the dll because I did not register the dll on my PC before. It seems that when I compile my project, vb6 automatically registers A.dll. Therefore it ran nomally on my PC. Therefore, I have coded my program to auto-register the A.dll itself. And I tested on my PC, it was ok. But again when I deployed to another PC, it doesn't work. QUESTION: Even after I unregistered the A.dll on my PC, I still can run my program normally! For some reason, vb6 keeps locking on to my dll. and I cant seem to unregister it. Therefore I am unable to test my auto-registering code! How can I unregister the A.dll on my PC, so that I can test out the auto-registering of the A.dll itself?? I would prefer to perform the testing on my PC than to deploy it over and over again to find out if my code works.
-
windows XP, vb6 My vb6 project requires to reference A.dll in order to run properly. In my PC, the compiled .exe program runs normally. BUT when i deployed it to another computer, it does not run normally. UNTIL I realised i have to register the dll on that computer. I did not realize it had to do with registering the dll because I did not register the dll on my PC before. It seems that when I compile my project, vb6 automatically registers A.dll. Therefore it ran nomally on my PC. Therefore, I have coded my program to auto-register the A.dll itself. And I tested on my PC, it was ok. But again when I deployed to another PC, it doesn't work. QUESTION: Even after I unregistered the A.dll on my PC, I still can run my program normally! For some reason, vb6 keeps locking on to my dll. and I cant seem to unregister it. Therefore I am unable to test my auto-registering code! How can I unregister the A.dll on my PC, so that I can test out the auto-registering of the A.dll itself?? I would prefer to perform the testing on my PC than to deploy it over and over again to find out if my code works.
blurboy wrote:
I did not realize it had to do with registering the dll because I did not register the dll on my PC before. It seems that when I compile my project, vb6 automatically registers A.dll.
True. When you compile a .DLL project under VB6, it automatically does the registration for you. Which makes sense because VB6 is only capable of tareting COM-based .DLL's. It can't generate a normal function .DLL.
blurboy wrote:
Therefore, I have coded my program to auto-register the A.dll itself.
This is normally handled by the installer for your app, not the app itself. But, it's still possible to do so long as you realize that not everyone who uses your app may be able to register a COM .DLL.
blurboy wrote:
Even after I unregistered the A.dll on my PC, I still can run my program normally! For some reason, vb6 keeps locking on to my dll. and I cant seem to unregister it. Therefore I am unable to test my auto-registering code!
REGSVR32 /u mydllname.dllwill unregister that .DLL files GUIDs. Once the registrations are gone, the bindings shouldn't work any more. But, there may be old GUID data from older versions of your .DLL that are still registered. There's no way to automatically remove all of those references out of the Registry. You'll have to hunt them down and remove them by hand.A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
blurboy wrote:
I did not realize it had to do with registering the dll because I did not register the dll on my PC before. It seems that when I compile my project, vb6 automatically registers A.dll.
True. When you compile a .DLL project under VB6, it automatically does the registration for you. Which makes sense because VB6 is only capable of tareting COM-based .DLL's. It can't generate a normal function .DLL.
blurboy wrote:
Therefore, I have coded my program to auto-register the A.dll itself.
This is normally handled by the installer for your app, not the app itself. But, it's still possible to do so long as you realize that not everyone who uses your app may be able to register a COM .DLL.
blurboy wrote:
Even after I unregistered the A.dll on my PC, I still can run my program normally! For some reason, vb6 keeps locking on to my dll. and I cant seem to unregister it. Therefore I am unable to test my auto-registering code!
REGSVR32 /u mydllname.dllwill unregister that .DLL files GUIDs. Once the registrations are gone, the bindings shouldn't work any more. But, there may be old GUID data from older versions of your .DLL that are still registered. There's no way to automatically remove all of those references out of the Registry. You'll have to hunt them down and remove them by hand.A guide to posting questions on CodeProject[^]
Dave KreskowiakREGSVR32 /u mydllname.dll will unregister that .DLL files GUIDs. Once the registrations are gone, the bindings shouldn't work any more. But, there may be old GUID data from older versions of your .DLL that are still registered. There's no way to automatically remove all of those references out of the Registry. You'll have to hunt them down and remove them by hand. Already tried so. REGSVR32 /u mydllname.dll. But when i double click on my exe to run. it still run normally!
-
REGSVR32 /u mydllname.dll will unregister that .DLL files GUIDs. Once the registrations are gone, the bindings shouldn't work any more. But, there may be old GUID data from older versions of your .DLL that are still registered. There's no way to automatically remove all of those references out of the Registry. You'll have to hunt them down and remove them by hand. Already tried so. REGSVR32 /u mydllname.dll. But when i double click on my exe to run. it still run normally!
Your best bet is a "clean build" PC to test on - I use VMWare Workstation for this - it allows you to rollback the state of the Virtual Machine so you can go back to "clean" for testing the installers. As for the mystery of it still working on your PC - it depends a bit on the way the DLL is called from VB - if you are using CreateObject as in e.g. wordObj = CreateObject("Word.Application") then the registry is searched first for Word.Application class then it picks up a GUID in that to get actual reg info point to the OLE DLL. This is known as "Late Binding". Early binding is what you get when you add the DLL to the references in your VB project. Can't remember for sure but there is a good chance that when you open the VB project if it is early bound and it doesn't find the registry info that it automatically re-registers the DLL - and it is likely it does this even if you don't run the project (because it needs the reference to be working to even allow a compile). I recommend ProcMon (old Sysinternals tool - now Microsoft) to spy on what is going on and ow the registry info for your DLL is being found.
-
windows XP, vb6 My vb6 project requires to reference A.dll in order to run properly. In my PC, the compiled .exe program runs normally. BUT when i deployed it to another computer, it does not run normally. UNTIL I realised i have to register the dll on that computer. I did not realize it had to do with registering the dll because I did not register the dll on my PC before. It seems that when I compile my project, vb6 automatically registers A.dll. Therefore it ran nomally on my PC. Therefore, I have coded my program to auto-register the A.dll itself. And I tested on my PC, it was ok. But again when I deployed to another PC, it doesn't work. QUESTION: Even after I unregistered the A.dll on my PC, I still can run my program normally! For some reason, vb6 keeps locking on to my dll. and I cant seem to unregister it. Therefore I am unable to test my auto-registering code! How can I unregister the A.dll on my PC, so that I can test out the auto-registering of the A.dll itself?? I would prefer to perform the testing on my PC than to deploy it over and over again to find out if my code works.
VB 6 will look in the WIN\system or system32 folders even if a dll is unregistered. To test your auto register you would need to either relocate the dll or rename it with a different suffix. Additionally, assure that the installer is adding the dll file to the new system. The Software Packager (To build the installation package) will have a step for you to indicate what files you want to add, especially if you are using a custom dll or ocx. The packager does not automatically assure that all the necessary dll’s are added. Simply dragging or copying an executable to a new machine does not add the needed dlls. The installer will add and register the dlls. Good luck
It was broke, so I fixed it.
-
windows XP, vb6 My vb6 project requires to reference A.dll in order to run properly. In my PC, the compiled .exe program runs normally. BUT when i deployed it to another computer, it does not run normally. UNTIL I realised i have to register the dll on that computer. I did not realize it had to do with registering the dll because I did not register the dll on my PC before. It seems that when I compile my project, vb6 automatically registers A.dll. Therefore it ran nomally on my PC. Therefore, I have coded my program to auto-register the A.dll itself. And I tested on my PC, it was ok. But again when I deployed to another PC, it doesn't work. QUESTION: Even after I unregistered the A.dll on my PC, I still can run my program normally! For some reason, vb6 keeps locking on to my dll. and I cant seem to unregister it. Therefore I am unable to test my auto-registering code! How can I unregister the A.dll on my PC, so that I can test out the auto-registering of the A.dll itself?? I would prefer to perform the testing on my PC than to deploy it over and over again to find out if my code works.