Sharross -<br><br>You shouldn't force the install of the VB5 runtime DLL. You should always compare the versions of the files and only copy it if your version is newer than the one currently on the user's disk. The InstallShield should take care of this for you (probably just a option to pick). Your programmers are right in that this file could be in many different directories, but <b>the</b> correct place for it is in the System directory (System32 if on NT). They should ignore the other copies for now. <br><br>This will cause support problems later but it can't be helped. What happens is other 3rd party vendors install their own copies of the DLL in their application directory. If the other vendor's program gets run before yours, their copy of the DLL gets loaded into memory. If your version and their version is incompatible, when they then go to run your app, it crashes because the wrong version of the DLL was loaded. If the users run the programs in the opposite order (yours, then theirs), their program crashes. This is known as "DLL Hell", and is a common problem. Microsoft has taken steps under Windows 2000 to resolve it, but until then, you're stuck. It's especially bad because it wasn't your fault (the other vendors wrote the DLL into a private directory), and yet your users are the ones who will be complaining. The usual support answer is to load the app on a clean machine and try it again. If it works, then it must have been an incompatibility with a 3rd party app and you're off the hook.<br><br>If you were asking how to require the novice users to download and install this patch from Microsoft, the answer is: You shouldn't. What you should do is install this patch on your own machine and then include the required files in your setup routine. You could even install the patch file behind the scenes if you tell the patch to do an automated install (don't show anything on the screen, take all parameters off the command line).<br><br>When creating setup routines, it is good practice to do this on a "clean" machine, so that you have more control over the versions of files that you ship. Typically (if your development shop is anything like mine), one or more of your developers is a download junkie and has installed everything he/she can get their greedy hands on. This causes problems when it's time to build a release copy of your product and later prepare the setup, as this person may be depending on a later version of a DLL or OCX than everyone else on the team has on their PCs.<br><br>Chip H.<br>