Randem Systems Support Board

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 cannot just 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 Run-time 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 Run-time files. They are in InnoScript (one word). Most people just use the ones on their system which most are OS dependent 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 run-time 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, and they have to work on something!

         A lot of talk is about saying that you do not need to deploy the VB Run-time files on certain OS's because they come with the VB Run-time files. You are talking a really big chance not deploying the correct run-time files (except on Vista, Windows 7 and Windows 8 ), 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 else's ill -conceived work? I don't. I always deploy the run-time 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 prefer 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 Run-time 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 Run-time 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 client's computer causing OS failure. Also when deploying MS Scripting Run-time (scrrun.dll) then whole MS Scripting Run-time 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 were 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, Windows 7 or Windows 8 DO NOT deploy the VB Run-time 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.Oh, and one more thing... NEVER use your development machine to test an installation (the deployment will always work). The reason you do not test on your deployment machine is because all the files that are needed are already there so you will never know if you have deployed all that you need to deploy. The second reason is that if you screw up a deployment you can wreck your development machine and have no idea of what went wrong (that is exactly what you will do to your clients machine also...). It is best to use a clean Virtual Machine to test your deployments. You can always start over with a clean machine each time you test so that you can be confident that you have done your installation correctly. If it doesn't work there it may not stand a chance on the clients machines. One Virtual Machine to use is Microsoft's Virtual PC 2007 (SP1) or Oracles VirtualBox. Once you create the VHD for your target OS, zip the VHD; then when you want to start over with a clean machine just unzip the VHD and you will now have a clean machine!



         Look at InnoScript to help you with most of these problems.