I ran into this same issue before the ATL security fix updates were released. We had to get a hot-fix from Microsoft for the Visual Studio 2005 C++ redistributable controls as installations of MS SQL 2005 would break our application due to being shipped with a post-SP1 version of the controls which had an obvious bug in them (wasn't fun trying to figure this out, I only actually reproduced it due to the Visual Studio Express Editions installing MS SQL 2005 Express by default which one of our non-code writing developers had installed to help him prototype something for a requirements spec's).
Unfortunately Richard's message came in an hour & half after I left the office & I don't check my work e-mail at weekends. Glad the accumulated knowledge of the list got to the bottom of it though =) Palbinder Sandher Software Deployment & IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the <Virtual Environment>** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -----Original Message----- From: Rob Hamflett [mailto:r...@snsys.com] Sent: 16 November 2009 09:37 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] best way to deploy C++ runtime? This thread has been really enlightening. Thanks everyone for the information. I had this issue a little while ago, with VS building against one version of the runtime and the merge modules delivering another. After a lot of searching online I finally found the code snippets to get VS to build against the latest version. I then had to go and update all our projects, including some 3rd party libraries. We've just come up foul of this again when my boss added a new project which didn't run properly because it was missing this special magic. It sounds like the policy files are pretty much required when deploying the VC runtime as this issue is really hard to track down. It certainly took me long enough to find a work around, and this thread has just shown me that I should have been including the policy files all along. I think the How-To guide in the WiX docs should definitely be updated so that they don't tell the reader that the policy files aren't needed. Actually, they say "There is generally no need..." However, since the update to VS that updated the merge modules, I don't think this is a fringe case anymore. Rob Richard wrote: > For the benefit of others, this appears to be by design. > > By default, your application is bound to the old runtime, even though > the merge modules get updated (so you can't distribute the old runtime > unless you saved a copy of the merge modules before you updated). > > However, if you define _BIND_TO_CURRENT_VCLIBS_VERSION=1 when > compiling your code, then the automatically generated manifest will > bind to the updated runtime. You have to define this from the project > options and you have to define it for all the runtime dependencies > used by your application in order for everything to be bound only to > the new runtime. > > Otherwise you must use the policy MSM and the new MSM to install the > new runtime and redirect users of the old runtime to the new one. Of > course, that might break some applications that depended on the > behavior of the old one compared to the new one... but if you use the > vcredist_x86.exe, its going to install the policy MSM anyway it seems. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
