Hi there,
I have an application, version 1.0 of which had a small (15 machines) but effective deployment using the Package & Deployment Wizard. A few bug-fixes later, I am ready to deploy 1.1 to a slightly wider user base - but now my package won't install!
I have been plagued by a series of errors in which the deployment wizard tells me that a windows system file is out of date (on the machine on which I am installing) and then asks me to replace the "out of date" file and restart windows. In each case the file to be replaced seems to be a _newer_ dll (not an older one) than the one on the machine on which the code is packaged. This has been the case with Msvcrt.dll and Msstdfmt.dll - in each case I am reluctant to allow my setup to replace more recent versions with an older version (although the package says it is up-dating, it actually contains an older version of the dll in question).
(Before this problem started I had a similar problem with scrrun.dll - somehow I have now a newer (and smaller) version of scrrun.dll on my machine than I had when compiling version 1.0 (8 weeks ago), but I still had a sccrun.dep file dated the same as the original scrrun.dll. To avoid "old version of dependency information" problems derailing my deployment, I had to copy back the old version of sccrun.dll to my Windows\System\ folder)
Does anyone have any tips on beating this kind of problem, or any information as to why different (but similar) machines on the same network should have different versions of these particular dlls, or as to why setup.exe tells me I'm installing a newer version of a dll when I'm installing an older version ?? All hints, tips and pointers gratefully received!
thanks
Mark
I have an application, version 1.0 of which had a small (15 machines) but effective deployment using the Package & Deployment Wizard. A few bug-fixes later, I am ready to deploy 1.1 to a slightly wider user base - but now my package won't install!
I have been plagued by a series of errors in which the deployment wizard tells me that a windows system file is out of date (on the machine on which I am installing) and then asks me to replace the "out of date" file and restart windows. In each case the file to be replaced seems to be a _newer_ dll (not an older one) than the one on the machine on which the code is packaged. This has been the case with Msvcrt.dll and Msstdfmt.dll - in each case I am reluctant to allow my setup to replace more recent versions with an older version (although the package says it is up-dating, it actually contains an older version of the dll in question).
(Before this problem started I had a similar problem with scrrun.dll - somehow I have now a newer (and smaller) version of scrrun.dll on my machine than I had when compiling version 1.0 (8 weeks ago), but I still had a sccrun.dep file dated the same as the original scrrun.dll. To avoid "old version of dependency information" problems derailing my deployment, I had to copy back the old version of sccrun.dll to my Windows\System\ folder)
Does anyone have any tips on beating this kind of problem, or any information as to why different (but similar) machines on the same network should have different versions of these particular dlls, or as to why setup.exe tells me I'm installing a newer version of a dll when I'm installing an older version ?? All hints, tips and pointers gratefully received!
thanks
Mark