Installation Problems?
Installing on Vista
Error accessing the OLE Registry. Error 0x8002801C
An ounce of prevention is worth a pound of cure!!!
But you didn't do that did you?
Installing on Vista
Error accessing the OLE Registry. Error 0x8002801C
An ounce of prevention is worth a pound of cure!!!
But you didn't do that did you?
NOTE: InnoScript is not the same as the Inno Setup Wizard that is included with Inno Setup. The Inno Setup Wizard will not find dependencies for your project as well as a few other thing you will need to complete your script. InnoScript is a separate package developed by a different company with no affiliation to Inno Setup.
The number one reason for problems with installations with VB application is when someone attempts to shortcut the installation process that is necessary for VB. Generally this is someone new to the installation process of VB applications. Many don't understand all that NEEDS to be done will have many problems. Use an installation package such as Inno Setup (free) COMBINED with InnoScript (not the Inno Setup Wizard) that will help you get all the dependencies and generate an installation script. This will help you avoid serious problems later. You just cannot copy your VB exe to another computer and expect it to work. This is a very common mistake for VB Beginners. Most beginners will probably state the most ridiculous reasoning for doing this. They will state "I copied the program to another computer before and it worked". Well, Duh! So, if you ran a stop light once and nothing happened your thinking should be that is the correct thing to do, HUH? Luck might just have something to do with that, eh. The reason that this may work in certain circumstances is that the files you need to deploy are already on the target machine possibly because someone else deployed their app correctly with the same files you need and so yours works. Now if the files do not exist for any reason and you do not deploy them... Guess What??? YOUR APP WON'T WORK!!!
The number one reason for problems with installations with VB application is when someone attempts to shortcut the installation process that is necessary for VB. Generally this is someone new to the installation process of VB applications. Many don't understand all that NEEDS to be done will have many problems. Use an installation package such as Inno Setup (free) COMBINED with InnoScript (not the Inno Setup Wizard) that will help you get all the dependencies and generate an installation script. This will help you avoid serious problems later. You just cannot copy your VB exe to another computer and expect it to work. This is a very common mistake for VB Beginners. Most beginners will probably state the most ridiculous reasoning for doing this. They will state "I copied the program to another computer before and it worked". Well, Duh! So, if you ran a stop light once and nothing happened your thinking should be that is the correct thing to do, HUH? Luck might just have something to do with that, eh. The reason that this may work in certain circumstances is that the files you need to deploy are already on the target machine possibly because someone else deployed their app correctly with the same files you need and so yours works. Now if the files do not exist for any reason and you do not deploy them... Guess What??? YOUR APP WON'T WORK!!!
If you are using Microsoft's Package and Deployment Wizard, You may be left scratching your head often with the different problems you will or have encountered. This package is very much outdated and hasn't been updated since 1998. The .dep files that it uses are out of date and will sometimes leave you looking for files that do not exist anywhere (especially if you use Crystal Reports 8.5). People argue that it is good enough for what they want to do and it's free. There are other free packages out there and they are current and will leave you with more hair on your head. PDW will commonly give you the error that some component cannot be updated or are outdated and they will need to restart. This will happen over and over again unless you update your VB Runtime files with the universal ones. Also look at other possible solutions
(reference - http://support.microsoft.com/kb/290887 )
As I understand it, the "NEW" Visual Studio Installer suffers from many of the same problems that PDW does. You can't add whole folders of files, It still tells you that something is missing and Please re-run the setup again (.net framework), etc, etc... You would think that since 1997, they would have gotten their heads around these problems. But it seems that PDW was just modified for VS not rewritten. There are such things as Universal VB Runtime files. They are in InnoScript (one word). Most people just use the ones on their system which most are OS dependant and should not be deployed on other OS systems (and people wonder why their XP app won't work properly on 98!!!).
Newer dll/ocx/exe make calls they were not supported in older OS systems and on an older system will create "Problems" when you make a call to a non-existing entry point or a function that has been changed to return different results than the older version. Let say that the old dll returns from a call a string and the new version of the same dll the same function now returns a long. What do you thinks would happen to code that was expecting a string. Some sort of failure would eventually happen if the code actually checked the return value.
The universal runtime files will return the same data type as the older version etc... The same thing would happen if one forced a older dll onto a newer system. But most installers automatically handle this one. But I have known some companies
(I will not name them) that actually force the outdated dll's onto your system. Want Proof? Install Access 97 on Windows XP, You will get an "Out of Memory Error" when you attempt to run Access 97. Do you know why? Because Access 97 forces old dll's on your updated system. Now run the Automatic OS Updater on your XP system and Wah-Lah, Access 97 works. Now if the the makers of Access 97 did not figure that out and they get you into trouble, do you think you should follow that lead? Other problems will probably exist also. So DON'T DO IT!!! Most people have a lack of understanding for installers and the OS in general. I cannot stress this enough but beginners keep trying it. Hey large companies hire beginners too, an they have to work on something!
A lot of talk is about saying that you do not need to deploy the VB Runtime files on certain OS's because they come with the VB Runtime files. You are talking a really big chance not deploying the correct runtime files (except on Vista), for if someone else deployed the wrong runtime files (you trust them don't you?) your app may not work properly. Do you want to risk your reputation on someone elses work? I don't. I always deploy the runtime file (except on Vista) because if you do and the correct runtime files are already there the ones you deploy won't be deployed anyway for they are the same version (if your installation package is set up correctly). Now, if they are not the same version... You will deploy the correct ones and your app will work. I perfer my apps working 100% of the time. 99% of the time or less is good for some but is not good enough for me.
Download the automatic or manual updater or the individual updates for your OS. If you are distributing your VB application, Always include the VB 6 Runtime Files in your installation package. They must be identical to the ones that we have included on this website. The ones that were installed in your system folder with VB or with your OS are not the correct one that should be distributed. They may be OS dependent (or just old) and should not be re-deployed. The VB files included here are universal files that will work on all the Windows Operating Systems (If the files are not needed they will not be installed over the newer ones for the OS).
Not having the destination computer properly updated with the correct Runtime files, latest Service Packs and MDAC's (Microsoft Data Access Components) is the number one problem with Visual Basic apps not being deployed properly. Especially if you are using databases. The number two problem is installing OS dependent file onto the clients computer causing OS failure. Also when deploying MS Scripting Runtime (scrrun.dll) then whole MS Scripting Runtime system should be deployed not just the one dll. The same goes for the MDAC files. This mistake happens more often than I care to remember. Reference: http://support.microsoft.com/kb/254166/. If you are using the dreaded Data Controls such as ADODC (basically any control ending in DC). You need to deploy a file vb5db.dll. From VB5 you ask? Yes that is how bad they are...
Example: You created an installation on Windows XP and deployed it to Windows 98. A file named MSVCRT.DLL is included in the setup program. This file is installed on Win 98 replacing the one included with Win 98. This will be allowed since the Win XP file is newer than the one on Win 98. Now this file cannot be used by Win 98 causing the system to act unpredictable and may even crash. Now you have just taken out your clients computer. What have you got to say for yourself now?... It wasn't me???. I don't think it worked for Shaggy, so I don't think it will work for you either.
Generally you should not deploy any files that was installed with the operating system without research... Let Microsoft's Service Packs install them (this is what MS does). So be careful and be sure of what you put into your installation to deploy. On Vista DO NOT deploy the VB Runtime files, they are already there. Inno Setup does have the ability to determine if the VB Runtime files should be deployed with the proper directives.
Look at InnoScript to help you with most of these problems.
(reference - http://support.microsoft.com/kb/290887 )
As I understand it, the "NEW" Visual Studio Installer suffers from many of the same problems that PDW does. You can't add whole folders of files, It still tells you that something is missing and Please re-run the setup again (.net framework), etc, etc... You would think that since 1997, they would have gotten their heads around these problems. But it seems that PDW was just modified for VS not rewritten. There are such things as Universal VB Runtime files. They are in InnoScript (one word). Most people just use the ones on their system which most are OS dependant and should not be deployed on other OS systems (and people wonder why their XP app won't work properly on 98!!!).
Newer dll/ocx/exe make calls they were not supported in older OS systems and on an older system will create "Problems" when you make a call to a non-existing entry point or a function that has been changed to return different results than the older version. Let say that the old dll returns from a call a string and the new version of the same dll the same function now returns a long. What do you thinks would happen to code that was expecting a string. Some sort of failure would eventually happen if the code actually checked the return value.
The universal runtime files will return the same data type as the older version etc... The same thing would happen if one forced a older dll onto a newer system. But most installers automatically handle this one. But I have known some companies
(I will not name them) that actually force the outdated dll's onto your system. Want Proof? Install Access 97 on Windows XP, You will get an "Out of Memory Error" when you attempt to run Access 97. Do you know why? Because Access 97 forces old dll's on your updated system. Now run the Automatic OS Updater on your XP system and Wah-Lah, Access 97 works. Now if the the makers of Access 97 did not figure that out and they get you into trouble, do you think you should follow that lead? Other problems will probably exist also. So DON'T DO IT!!! Most people have a lack of understanding for installers and the OS in general. I cannot stress this enough but beginners keep trying it. Hey large companies hire beginners too, an they have to work on something!
A lot of talk is about saying that you do not need to deploy the VB Runtime files on certain OS's because they come with the VB Runtime files. You are talking a really big chance not deploying the correct runtime files (except on Vista), for if someone else deployed the wrong runtime files (you trust them don't you?) your app may not work properly. Do you want to risk your reputation on someone elses work? I don't. I always deploy the runtime file (except on Vista) because if you do and the correct runtime files are already there the ones you deploy won't be deployed anyway for they are the same version (if your installation package is set up correctly). Now, if they are not the same version... You will deploy the correct ones and your app will work. I perfer my apps working 100% of the time. 99% of the time or less is good for some but is not good enough for me.
Download the automatic or manual updater or the individual updates for your OS. If you are distributing your VB application, Always include the VB 6 Runtime Files in your installation package. They must be identical to the ones that we have included on this website. The ones that were installed in your system folder with VB or with your OS are not the correct one that should be distributed. They may be OS dependent (or just old) and should not be re-deployed. The VB files included here are universal files that will work on all the Windows Operating Systems (If the files are not needed they will not be installed over the newer ones for the OS).
Not having the destination computer properly updated with the correct Runtime files, latest Service Packs and MDAC's (Microsoft Data Access Components) is the number one problem with Visual Basic apps not being deployed properly. Especially if you are using databases. The number two problem is installing OS dependent file onto the clients computer causing OS failure. Also when deploying MS Scripting Runtime (scrrun.dll) then whole MS Scripting Runtime system should be deployed not just the one dll. The same goes for the MDAC files. This mistake happens more often than I care to remember. Reference: http://support.microsoft.com/kb/254166/. If you are using the dreaded Data Controls such as ADODC (basically any control ending in DC). You need to deploy a file vb5db.dll. From VB5 you ask? Yes that is how bad they are...
Example: You created an installation on Windows XP and deployed it to Windows 98. A file named MSVCRT.DLL is included in the setup program. This file is installed on Win 98 replacing the one included with Win 98. This will be allowed since the Win XP file is newer than the one on Win 98. Now this file cannot be used by Win 98 causing the system to act unpredictable and may even crash. Now you have just taken out your clients computer. What have you got to say for yourself now?... It wasn't me???. I don't think it worked for Shaggy, so I don't think it will work for you either.
Generally you should not deploy any files that was installed with the operating system without research... Let Microsoft's Service Packs install them (this is what MS does). So be careful and be sure of what you put into your installation to deploy. On Vista DO NOT deploy the VB Runtime files, they are already there. Inno Setup does have the ability to determine if the VB Runtime files should be deployed with the proper directives.
Look at InnoScript to help you with most of these problems.
Randem Systems
Your Installation Specialist
Your Installation Specialist
All Support is Done Thru Our Support Board. Let us know what you think...
http://www.randem.com/cgi-bin/discus/discus.cgi
http://www.randem.com/cgi-bin/discus/discus.cgi