I have run the package and deployment wizard on my database application and everything seemed to go well. When I run setup on another computer I get a message saying "Setup cannot continue because some system files are out of date on your system" after processing about 19 files. It goes on to say press OK to update or Cancel to close out of the setup. Seems straight forward so I hit OK to allow the computer to do the updates and restart, but when I tried to install again it tries to install only three files that were supposedly updated. I followed the same steps as before, but after each restart I have to update three files, one of which flashes on the screen too fast to read. They are VB6STKIT.DLL and msvcrt.dll and they are listed in the list of dependancies that package and deployment wizard has recognized as necceassary for my application. I would appreciate any help on this subject.
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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
DLL problems, vb6stkit.dll, msvcrt.dll 7
- Thread starter bzsurf03
- Start date
- Thread starter
- #2
- Thread starter
- #3
-
2
- #4
- Thread starter
- #5
- Thread starter
- #6
With those OSes, it's not the problem I was remembering.
PDW is, uh, not the best tool for the job. How about trying another installer, such as INNO Setup. It's free. Get it at
HTH,
David
PDW is, uh, not the best tool for the job. How about trying another installer, such as INNO Setup. It's free. Get it at
Code:
[URL unfurl="true"]http://www.jrsoftware.org/isinfo.php[/URL]David
- Thread starter
- #8
SeanGriffin
Programmer
Have you ever noticed that window 2K Protects certian "System" Files? (Notepad.exe included) If you try to delete/Update any of these files without useing a windows update Windows will not allow it.
I believe your files may fall under this list.
If so you're attempting to change files your not allowed to so Windows will replace them with the originals. I have yet to find a nice way around this issue.
-Sean
I believe your files may fall under this list.
If so you're attempting to change files your not allowed to so Windows will replace them with the originals. I have yet to find a nice way around this issue.
-Sean
-
3
- #11
Hello.
I ran into this problem creating a package with the PDW, and apparently the problem is widespread. In my case, I was creating the package on an XP system and attempting to install it on a Win2000 system.
The problem arises when the package has system files (if you open SETUP.LST, you will find that files that are installed to $(WinSysPathSysFile) are candidates to cause this problem. Here is an example from my travels:
File9=@msjtes40.dll,$(WinSysPathSysFile),$(DLLSelfRegister),,4/2/02 10:51:52 AM,241695,4.0.5914.0
Note the last part of the string: 4.0.5914.0. This is the version number of the copy of the file on the machine creating the package. On the install machine, there is an earlier version, which you can verify by finding the file (should be WINxxxx/SYSTEM32 directory) and checking the version in its properties. This situation will raise our by now familiar error message.
All of the fixes (add service packs, make sure the temp file is in the right place, etc. etc.) are attempts to upgrade the existing system file to the one in the package. The common thread in all of the problems is the attempt to install a newer version of a system dll on top of an older version being used by the installee system. This is especially a problem when using XP (and probaby Win2003 as well) to create packages that are intended for Win2000 systems.
Solutions differ for Win9x and Win2000 systems.
In neither opsys type can one overwrite a system file dll: by definition, the system is using it and prevents a full lock.
Win 9x: Win 9x systems, when encountering a newer version of a system file, write the file to the temp directory (specified by the set temp and set tmp commands). On bootup, the system looks in the temp directory and overwrites older system files with newer ones in said directory. This works fine, assuming the opsys can find the temp directory and the files haven't been erased. Workarounds to these problems are well-documented and basically trivial.
Win 2000: According to the Microsoft documentation:
"Both installation programs (ASW and PDW) use the same method to delay the replacement of in-use system files until reboot. For any system files that are in use, the new files are saved as temporary files in the Temp folder. In order to replace the existing files with the .tmp files, the system will use the Wininit.ini file on WIN 9x systems. On Windows NT and Windows 2000, the system will call the MoveFileEx function with the MOVEFILE_REPLACE_EXISTING flag. This function places the file replacement instructions in the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
If something interferes with this replace and rename operation, these files are not updated. Therefore, once the computer reboots and restarts the installation program, the same error message appears."
I ran the offending SETUP.EXE file, got my error message, and started looking around. I was unable to find a "PendingFileRenameOperations" key under SessionManager, although I did find a "FileRenameOperations" key with no value set. Second, I was unable to find any temp files in the temp directory. Although it is possible that I made some sort of arcane setting on the several test systems I have been using to prevent the documented behavior, my practical conclusion is that Win2000 systems do not allow the direct overwriting of system files, despite suggestions to the contrary in this documentation.
The overwriting of system files can be accomplished through the installation of service packs. However, Win2000 service packs cannot be expected to have system dll's that are up to date in terms of WinXP/2003 environments.
The important ramification of these conclusions is that PDW packages created on systems later than Win2000 with no service packs are not downwardly compatible with Win2000 systems with earlier service packs, and in a less than gracious fashion to boot.
Therefore, the most "foolproof" packaging strategy is to keep a machine or virtual machine with a Win2000 opsys with no service pack, or an earlier Win 9x or NT machine. Do your development on whatever system you like, but use the PDW on this machine. This will ship old versions of the system files that will not be installed.
Bob Rodes
I ran into this problem creating a package with the PDW, and apparently the problem is widespread. In my case, I was creating the package on an XP system and attempting to install it on a Win2000 system.
The problem arises when the package has system files (if you open SETUP.LST, you will find that files that are installed to $(WinSysPathSysFile) are candidates to cause this problem. Here is an example from my travels:
File9=@msjtes40.dll,$(WinSysPathSysFile),$(DLLSelfRegister),,4/2/02 10:51:52 AM,241695,4.0.5914.0
Note the last part of the string: 4.0.5914.0. This is the version number of the copy of the file on the machine creating the package. On the install machine, there is an earlier version, which you can verify by finding the file (should be WINxxxx/SYSTEM32 directory) and checking the version in its properties. This situation will raise our by now familiar error message.
All of the fixes (add service packs, make sure the temp file is in the right place, etc. etc.) are attempts to upgrade the existing system file to the one in the package. The common thread in all of the problems is the attempt to install a newer version of a system dll on top of an older version being used by the installee system. This is especially a problem when using XP (and probaby Win2003 as well) to create packages that are intended for Win2000 systems.
Solutions differ for Win9x and Win2000 systems.
In neither opsys type can one overwrite a system file dll: by definition, the system is using it and prevents a full lock.
Win 9x: Win 9x systems, when encountering a newer version of a system file, write the file to the temp directory (specified by the set temp and set tmp commands). On bootup, the system looks in the temp directory and overwrites older system files with newer ones in said directory. This works fine, assuming the opsys can find the temp directory and the files haven't been erased. Workarounds to these problems are well-documented and basically trivial.
Win 2000: According to the Microsoft documentation:
"Both installation programs (ASW and PDW) use the same method to delay the replacement of in-use system files until reboot. For any system files that are in use, the new files are saved as temporary files in the Temp folder. In order to replace the existing files with the .tmp files, the system will use the Wininit.ini file on WIN 9x systems. On Windows NT and Windows 2000, the system will call the MoveFileEx function with the MOVEFILE_REPLACE_EXISTING flag. This function places the file replacement instructions in the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
If something interferes with this replace and rename operation, these files are not updated. Therefore, once the computer reboots and restarts the installation program, the same error message appears."
I ran the offending SETUP.EXE file, got my error message, and started looking around. I was unable to find a "PendingFileRenameOperations" key under SessionManager, although I did find a "FileRenameOperations" key with no value set. Second, I was unable to find any temp files in the temp directory. Although it is possible that I made some sort of arcane setting on the several test systems I have been using to prevent the documented behavior, my practical conclusion is that Win2000 systems do not allow the direct overwriting of system files, despite suggestions to the contrary in this documentation.
The overwriting of system files can be accomplished through the installation of service packs. However, Win2000 service packs cannot be expected to have system dll's that are up to date in terms of WinXP/2003 environments.
The important ramification of these conclusions is that PDW packages created on systems later than Win2000 with no service packs are not downwardly compatible with Win2000 systems with earlier service packs, and in a less than gracious fashion to boot.
Therefore, the most "foolproof" packaging strategy is to keep a machine or virtual machine with a Win2000 opsys with no service pack, or an earlier Win 9x or NT machine. Do your development on whatever system you like, but use the PDW on this machine. This will ship old versions of the system files that will not be installed.
Bob Rodes
Hi Bob,
Terrific explanation! However, while your final strategy might be almost foolproof, I think there's still a hole in it.
If you're distributing system files, presumably you require some functionality those files provide. This functionality might differ or be absent in the baseline PDW platform you describe.
Recipients of your distribution could have versions of system files that range anywhere between your baseline PDW environment and your development environment. Thus, while you avoid installation problems by delivering old system files, your software might fail on systems with outdated (compared to your development system) system files. You're still going to get the trouble calls; you'll just be helping users install service packs.
While taking the chance that your program won't work isn't an optimum solution, I have to admit that it's better than an installation package that destroys the OS on the user's computer.
(And PDW has been known to do that. I have first-hand experience with that one.)
Terrific explanation! However, while your final strategy might be almost foolproof, I think there's still a hole in it.
If you're distributing system files, presumably you require some functionality those files provide. This functionality might differ or be absent in the baseline PDW platform you describe.
Recipients of your distribution could have versions of system files that range anywhere between your baseline PDW environment and your development environment. Thus, while you avoid installation problems by delivering old system files, your software might fail on systems with outdated (compared to your development system) system files. You're still going to get the trouble calls; you'll just be helping users install service packs.
While taking the chance that your program won't work isn't an optimum solution, I have to admit that it's better than an installation package that destroys the OS on the user's computer.
(And PDW has been known to do that. I have first-hand experience with that one.)I take your point, but my theory is that system files support the system on which they are installed, rather than the application which runs on them. I did consider the idea that an application developed on a later system might require functionality that is not present in an earlier version of a system file, but it seems most unlikely to me, given that system functionality is encapsulated apart from application functionality. So, it seems the least of several evils to me, hence the suggestion. If not, why then use Win2000 without service packs as the development machine, thumbing your nose at the Microsoft Marketing Juggernaut.
Bob
Bob
my theory is that system files support the system on which they are installed, rather than the application which runs on them
Which begs the question, then why do you have to distribute system files with your application?
Basically I agree with you. It's just that reality sometimes gets in the way.
Which begs the question, then why do you have to distribute system files with your application?
Basically I agree with you. It's just that reality sometimes gets in the way.
Very good question, which I am asking myself at this time since as you may have guessed, I'm knee deep in the middle of a packaging monster. I'm leaning towards keeping them, just in case I have a customer install where someone is missing a system file entirely. In the end, it's a matter of whether there will be more problems if I do or if I don't.
What do you think? You seem to have more practical experience with this than I do.
Bob Rodes
What do you think? You seem to have more practical experience with this than I do.
Bob Rodes
First, warn in the strongest possible terms Win9x users to create a DOS boot disk before proceeding with installation. (Not kidding!) MSI, which will be retrofitted to those systems, can make them unbootable.
Second, consider using an installer other than PDW. I've mentioned INNO before and there are other free installers, too. You could buy one like InstallShield, but since they're all now just shells for MSI, it doesn't make sense economically.
Finally, test and package your application on a clean machine with whatever service packs you need. And when you distribute, be prepared to answer trouble calls. Let's face it: users do screwy things on their systems (e.g. deleting the temp directory, "storing" all their working documents in the recycle bin to make their desktop tidy. Installation headache, anyone?)
I know it's fatalistic advice, but there's a Russian proverb that for me has always fit distros: "Hope for the best, expect the worst." Then some of the problems are always good for a laugh! ("Why yes, comrade, installing my software could indeed eliminate the contents of your recycle bin!"
Second, consider using an installer other than PDW. I've mentioned INNO before and there are other free installers, too. You could buy one like InstallShield, but since they're all now just shells for MSI, it doesn't make sense economically.
Finally, test and package your application on a clean machine with whatever service packs you need. And when you distribute, be prepared to answer trouble calls. Let's face it: users do screwy things on their systems (e.g. deleting the temp directory, "storing" all their working documents in the recycle bin to make their desktop tidy. Installation headache, anyone?)
I know it's fatalistic advice, but there's a Russian proverb that for me has always fit distros: "Hope for the best, expect the worst." Then some of the problems are always good for a laugh! ("Why yes, comrade, installing my software could indeed eliminate the contents of your recycle bin!"
Its not that stupid bit that hides in setup regarding DLL registering is it. Something about self registering but the wording in the script is wrong and you have to change it. Might, Might, Might be wrong, but may jog someone else to come in on it.
Thanks for the advice, and a well deserved star. Now that you mention MSI files, have you ever tried using Visual Studio Installer with VB stuff? The thing I'm working with uses it for a very complicated VB app, you know, one of those things that started with VB2 and just wouldn't die. It calls water meters on the telephone and keeps track of all the readings. The guy who wrote it (all by himself) is a real cowboy, started with those vacuum tube things in the early 60s that had 4k of ram and filled a room and used light bulbs and switches to accept machine language instructions. He wants me to get up to speed on this, and it seems pretty well undocumented except for J++ programs.
TIA
Bob
TIA
Bob
Hey, *I* started with vacuum tube things in the 60s, etc! I was also a "Beta Test Site Coordinator" for Visual Basic for DOS. (Still have golden release new, in box... what am I bid? Or do I have to move this thread to eBay?)
But to answer your question, no, I haven't used the VS installer with VB.
But to answer your question, no, I haven't used the VS installer with VB.
-
1
- #20
Bob,
I had this exact problem you have listed above. The way I ended up getting round it was to decrease the version number to as low as possible.
Sorry if someone has already sadi this, but....
If you use the dll help library, you cna work out what this:
I currently don't have problems with this part of the installation as if the file exists, it is good enough, and if it doesn't, you copy a recent version on!
On a slightly unrelated note: Does anyone knopw the best way to update an installation written using the PDW? If not, does anyone know how to use a different deployment package to update the current installation??
I had this exact problem you have listed above. The way I ended up getting round it was to decrease the version number to as low as possible.
Sorry if someone has already sadi this, but....
If you use the dll help library, you cna work out what this:
I currently don't have problems with this part of the installation as if the file exists, it is good enough, and if it doesn't, you copy a recent version on!
On a slightly unrelated note: Does anyone knopw the best way to update an installation written using the PDW? If not, does anyone know how to use a different deployment package to update the current installation??
- Status
