My VB6 app works fine when I run it on my dev machine. But when I compile and drop it on a server I get a 429 error and it tries to register a DLL. This system worked well until one day I thought the DLL had quote that should have been modifed. I made a copy of the DLL and renamed it, then pointed the program to the new DLL. Then I found that it wasn't the DLL causing the problem, but bad data instead. I tired fixing the code to just use the old DLL, but its been screwed up ever since. I can compile a good exe on others computers, but not on mine. Please help!
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
error 429 in VB6
- Thread starter 10Miler
- Start date
dilettante
MIS
Compile and drop" is not a valid deployment technique. Your VB6 program will try to register any unregistered OCX or DLL it tries to use if it can trip over it via DLL Search. Usually this occurs when the DLL in question is placed "next to" the EXE (i.e. in the same folder). This can lead to breakage of other programs on the same machine that use these same components, and thus it is almost always a bad idea to put component libraries in the same folder as code that uses them.
Using a proper installer or registration-free COM will help avoid this form of DLL Hell. Never use Win2K-style .EXE.LOCAL files. They are deprecated for good reasons, and were never meant to be used by a program consuming component libraries compiled with VB. VB 5/6 cannot create the proper self-registration entrypoint logic for use with the .LOCAL technique.
DLL/COM Redirection
Your main problem is probably a failure to maintain COM interface ("binary") compatibility though. You are probably letting VB generate new class ID values every time you compile these DLLs/OCXs even when there has not been a change in the interface.
You will find binary compatibility documented in the VB6 Component Tools Guide under Version Compatibility in ActiveX Components.
In the short term you might try carefully unregistering your component libraries on the server that has a problem. This may well require manual registry cleaning, a tedious process to be sure if you have no record of the different class IDs (GUID/UUIDs) you used.
Using a proper installer or registration-free COM will help avoid this form of DLL Hell. Never use Win2K-style .EXE.LOCAL files. They are deprecated for good reasons, and were never meant to be used by a program consuming component libraries compiled with VB. VB 5/6 cannot create the proper self-registration entrypoint logic for use with the .LOCAL technique.
DLL/COM Redirection
"Currently" was a hopeful qualifier, but since we never got a real VB7 this will never be addressed. In any case we have reg-free COM now, which is much cleaner anyway.
Your main problem is probably a failure to maintain COM interface ("binary") compatibility though. You are probably letting VB generate new class ID values every time you compile these DLLs/OCXs even when there has not been a change in the interface.
You will find binary compatibility documented in the VB6 Component Tools Guide under Version Compatibility in ActiveX Components.
In the short term you might try carefully unregistering your component libraries on the server that has a problem. This may well require manual registry cleaning, a tedious process to be sure if you have no record of the different class IDs (GUID/UUIDs) you used.
- Thread starter
- #3
have you tried unregistering the bad dll and then registering the good one.
remove reference in VB to bad dll
regsvr32 /u "C:WINNT\System32\Bad.dll"
regsvr32 "C:WINNT\System32\Good.dll"
add reference in VB6 to good dll
recompile
unregister and register in server
remove reference in VB to bad dll
regsvr32 /u "C:WINNT\System32\Bad.dll"
regsvr32 "C:WINNT\System32\Good.dll"
add reference in VB6 to good dll
recompile
unregister and register in server
- Thread starter
- #5
substitute 'bad' with 'the dll that is causing the problem'.
you say you changed the dll.
maybe I am misunderstanding you.
I have come accross this kind of problem before and the following usually fixes it.
1. remove reference fromm VB progect and save project.
2. unregister the dll.
3. recompile the dll
4. register the dll
5. add the ref to the dll to the vb project and recompile.
you say you changed the dll.
maybe I am misunderstanding you.
I have come accross this kind of problem before and the following usually fixes it.
1. remove reference fromm VB progect and save project.
2. unregister the dll.
3. recompile the dll
4. register the dll
5. add the ref to the dll to the vb project and recompile.
- Thread starter
- #7
Part of the problem with all this is that where I work I have to develop the app on a standalone machine, then copy everything over to a test server.
keenanbr,
I did change the DLL, but then went back to the old one. When I compile on any other machine it works fine, just not on mine.
Also fyi I just got Excel 2007 on my non-dev machine. This doesn't appear to be the problem though as there are others with Excel 2007 that use this app with no problems.
keenanbr,
I did change the DLL, but then went back to the old one. When I compile on any other machine it works fine, just not on mine.
Also fyi I just got Excel 2007 on my non-dev machine. This doesn't appear to be the problem though as there are others with Excel 2007 that use this app with no problems.
- Thread starter
- #8
- Thread starter
- #9
- Thread starter
- #11
- Thread starter
- #12
- Status
Similar threads
