MFC80 and MSVCR80 file versions
in [MFC]
|
Prev: Detecting Memory leak in Visual Studio (Debug mode)
Next: How can modeless dialog close parent dialog?
From: GT on 4 May 2010 10:36 We're having problems with our application on one of 4 PCs here. The application install updates system DLLS using merge modules. According to Depends.exe, our latest build has started looking for a newer version of the MFC80 and MSVCR80 files - it now requires Version 8.0.50727.4053, but we don't have this file on one of our target PCs. I include the MFC80 merge module in my install, but that merge module doesn't seem to contain the 8.0.50727.4053 build of the file, but uses the older .762 version. We have tried to install the VCRedist on the target PC, but that hasn't installed the 2 necessary DLLs either - the VCRedist file on the microsoft website is flagged as version .762 as well. Reading around suggests that a security update has patched my VS2005 development PC to update these files - kb973923, but I don't believe that Microsoft would have updated the system files on development PCs (through a security update), without providing a mechanism for developers distribute these 'common' files to customers. Their VCRedist file is still the old .762 version! What is the best way of getting those files onto and registered on the target PC during a standard install of our application. Perhaps I can force my application to use the older version of the MFC and MSVCR files? Help!!
From: David Ching on 4 May 2010 12:20 "GT" <ContactGT_rem_ove_(a)hotmail.com> wrote in message news:4be03082$0$7168$c3e8da3(a)news.astraweb.com... > We're having problems with our application on one of 4 PCs here. The > application install updates system DLLS using merge modules. According to > Depends.exe, our latest build has started looking for a newer version of > the MFC80 and MSVCR80 files - it now requires Version 8.0.50727.4053, but > we don't have this file on one of our target PCs. I include the MFC80 > merge module in my install, but that merge module doesn't seem to contain > the 8.0.50727.4053 build of the file, but uses the older .762 version. We > have tried to install the VCRedist on the target PC, but that hasn't > installed the 2 necessary DLLs either - the VCRedist file on the microsoft > website is flagged as version .762 as well. > > Reading around suggests that a security update has patched my VS2005 > development PC to update these files - kb973923, but I don't believe that > Microsoft would have updated the system files on development PCs (through > a security update), without providing a mechanism for developers > distribute these 'common' files to customers. Their VCRedist file is still > the old .762 version! > > What is the best way of getting those files onto and registered on the > target PC during a standard install of our application. > > Perhaps I can force my application to use the older version of the MFC and > MSVCR files? > GT, your research is correct, the DLL's were updated in a security release from .762 to .4053. When your development PC (with VC 2005 installed) was patched by Windows Update, it should have updated the files in your <VC install dir>\vc\redist. This was good enough for me because I do app-local installs and don't use either vc_redist.exe or merge modules. I recommend sticking with merge modules especially if that's what you've previously done. vc_redist.exe is not as preferable given running another ..exe from your installer, and it adds it's own Add/Remove Program shortcuts which if your users mistakenly remove it, will render your app unoperational. See http://social.msdn.microsoft.com/Forums/en-SG/vcgeneral/thread/0b4a06ce-5bb1-4056-9029-bdab8672a932 for more. -- David
From: GT on 5 May 2010 09:13
"David Ching" <dc(a)remove-this.dcsoft.com> wrote in message news:8561CD10-A921-48EB-9A00-FF57F3F22673(a)microsoft.com... > "GT" <ContactGT_rem_ove_(a)hotmail.com> wrote in message > news:4be03082$0$7168$c3e8da3(a)news.astraweb.com... >> We're having problems with our application on one of 4 PCs here. The >> application install updates system DLLS using merge modules. According to >> Depends.exe, our latest build has started looking for a newer version of >> the MFC80 and MSVCR80 files - it now requires Version 8.0.50727.4053, but >> we don't have this file on one of our target PCs. I include the MFC80 >> merge module in my install, but that merge module doesn't seem to contain >> the 8.0.50727.4053 build of the file, but uses the older .762 version. We >> have tried to install the VCRedist on the target PC, but that hasn't >> installed the 2 necessary DLLs either - the VCRedist file on the >> microsoft website is flagged as version .762 as well. >> >> Reading around suggests that a security update has patched my VS2005 >> development PC to update these files - kb973923, but I don't believe that >> Microsoft would have updated the system files on development PCs (through >> a security update), without providing a mechanism for developers >> distribute these 'common' files to customers. Their VCRedist file is >> still the old .762 version! >> >> What is the best way of getting those files onto and registered on the >> target PC during a standard install of our application. >> >> Perhaps I can force my application to use the older version of the MFC >> and MSVCR files? >> > > GT, your research is correct, the DLL's were updated in a security release > from .762 to .4053. When your development PC (with VC 2005 installed) was > patched by Windows Update, it should have updated the files in your <VC > install dir>\vc\redist. This was good enough for me because I do > app-local installs and don't use either vc_redist.exe or merge modules. > > I recommend sticking with merge modules especially if that's what you've > previously done. vc_redist.exe is not as preferable given running another > .exe from your installer, and it adds it's own Add/Remove Program > shortcuts which if your users mistakenly remove it, will render your app > unoperational. Problem was that i didn't have the .4053 merge modules!... When my executable started using the .4053 MFC DLLS, I googled this version and eventually discovered the kb973923 VS2005 patch and I assumed that my machine had been automatically updated and I just didn't know. I wanted to stick with merge modules as that is how my install is written already and it means our customers run a single install. However, the problem is that I didn't have the .4053 versions of the merge modules or the VCRedist on my machine - they are all still version .762. Turns out that the security patch in question hadn't been installed on my PC - I just presumed it had hapenned automatically when my executable suddenly started asking for the .4053 versions. The 'real' cause in my case was that the license software that we statically built into our software *had* been upgraded to the .4053 and I didn't know. I have applied the patch to my VS2005 and my merge modules and my VCRedist are now .4053. Thanks for the help. |