[WiX-users] best way to deploy C++ runtime?

[Richard]

OK, so I need to deploy the VS 2008 C++ runtime (w/ATL security fix)
and I'm reading the documentation in Visual Studio that says that
using the merge modules will install the runtime as side-by-side
assemblies. Further, it says that this will require administrative
priveleges in order to install the side-by-side assemblies. I'd like
to avoid administrative priveleges if possible. The documentation
says that my alternative is to deploy the C++ runtime as a private
assembly (i.e. just plunk the files down where my EXE lives).

I'm curious what other people have done here. In the past, products I
worked on always required administrative priveleges, so it wasn't an
issue, but the product I'm working on now is more like consumer shrink
wrap software and I want to make things as simple as possible.

How did all of you deal with this?

Did Windows Installer elevate the priveleges automatically so that you
didn't need to install the application as administrator?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

[Blair]

There are two ways: If you use the runtime in SxS "shared" mode, it can only
be installed after granting admin privileges (whether you use the MSM or the
EXE installer). If OTOH you use the "isolated" mode (aka private assembly),
then you only require the privileges that the directory you are writing into
require.

Even though Windows Installer runs your installation script from a service
running as "SYSTEM", it will only perform privileged actions (including
writing files without impersonating you) if you elevate the installation
somehow.

Most consumers are used to installations that require admin privileges,
except for the software that runs inside their browser (and even much of
that requires elevation to install) and many even come to expect it
(unfortunately).

If you are trying to deploy into a browser (a la ActiveX) the best bet is to
do the private assembly route which will allow you to deploy a perUser
installation that doesn't require any elevation (unless something else you
are doing does require elevation).

If you are forced by any other constraint to elevate your setup, make it a
perMachine installation (especially on platforms without UAC) and install
the runtime in SxS "shared" mode (either MSM or EXE installer) which will
allow for the possibility of MSFT servicing of the runtime (which they can't
do in isolated mode).

-----Original Message-----
From: Richard [mailto:***@xmission.com]
Sent: Tuesday, November 10, 2009 9:41 PM
To: wix-***@lists.sourceforge.net
Subject: [WiX-users] best way to deploy C++ runtime?

OK, so I need to deploy the VS 2008 C++ runtime (w/ATL security fix)
and I'm reading the documentation in Visual Studio that says that
using the merge modules will install the runtime as side-by-side
assemblies. Further, it says that this will require administrative
priveleges in order to install the side-by-side assemblies. I'd like
to avoid administrative priveleges if possible. The documentation
says that my alternative is to deploy the C++ runtime as a private
assembly (i.e. just plunk the files down where my EXE lives).

I'm curious what other people have done here. In the past, products I
worked on always required administrative priveleges, so it wasn't an
issue, but the product I'm working on now is more like consumer shrink
wrap software and I want to make things as simple as possible.

How did all of you deal with this?

Did Windows Installer elevate the priveleges automatically so that you
didn't need to install the application as administrator?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

----------------------------------------------------------------------------
--
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

[mrtn]

Hi Richard,

If you find a mergemodule og make your own, can you please share it with me
and the other readers. Last time I used time on this, Microsoft did not have
a mergemodule, only a .exe file.

//mrtn


Richard-45 wrote:
>
> OK, so I need to deploy the VS 2008 C++ runtime (w/ATL security fix)
> and I'm reading the documentation in Visual Studio that says that
> using the merge modules will install the runtime as side-by-side
> assemblies. Further, it says that this will require administrative
> priveleges in order to install the side-by-side assemblies. I'd like
> to avoid administrative priveleges if possible. The documentation
> says that my alternative is to deploy the C++ runtime as a private
> assembly (i.e. just plunk the files down where my EXE lives).
>
> I'm curious what other people have done here. In the past, products I
> worked on always required administrative priveleges, so it wasn't an
> issue, but the product I'm working on now is more like consumer shrink
> wrap software and I want to make things as simple as possible.
>
> How did all of you deal with this?
>
> Did Windows Installer elevate the priveleges automatically so that you
> didn't need to install the application as administrator?
> --
> "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
> <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
>
> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
>
> ------------------------------------------------------------------------------
> 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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>

--
View this message in context: http://n2.nabble.com/best-way-to-deploy-C-runtime-tp3984609p3985295.html
Sent from the wix-users mailing list archive at Nabble.com.

[Pally Sandher]

Mrtn you need the appropriate version of Visual Studio installed to get
the merge modules. They appear in C:\Program Files (x86)\Common
Files\Merge Modules\ after installation.

Richard what you're asking for is impossible. If you use either the
merge modules or bootstrap the equivalent VC++ redistributable it will
install to the WinSXS directory which is under the Windows directory.
You can't make changes to that area without the user having
administrator privileges. As far as I'm aware you can't simply drop the
files in with your application since the advent of Visual Studio 2005
(we used to do exactly that with VS2003 but I had to change our
installers to use the merge modules when we migrated to VS2005).

If you have Visual Studio 2008 installed & apply the ATL security fix it
will update your merge modules accordingly. I have both VS2005 & VS2008
installed & can confirm both update as expected with the appropriate
patches installed.

Palbinder Sandher
Software Deployment & IT Administrator
T: [phone]
F: [phone]

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: mrtn [mailto:***@gmail.com]
Sent: 11 November 2009 09:32
To: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] best way to deploy C++ runtime?


Hi Richard,

If you find a mergemodule og make your own, can you please share it with
me and the other readers. Last time I used time on this, Microsoft did
not have a mergemodule, only a .exe file.

//mrtn


Richard-45 wrote:
>
> OK, so I need to deploy the VS 2008 C++ runtime (w/ATL security fix)
> and I'm reading the documentation in Visual Studio that says that
> using the merge modules will install the runtime as side-by-side
> assemblies. Further, it says that this will require administrative
> priveleges in order to install the side-by-side assemblies. I'd like
> to avoid administrative priveleges if possible. The documentation
> says that my alternative is to deploy the C++ runtime as a private
> assembly (i.e. just plunk the files down where my EXE lives).
>
> I'm curious what other people have done here. In the past, products I

> worked on always required administrative priveleges, so it wasn't an
> issue, but the product I'm working on now is more like consumer shrink

> wrap software and I want to make things as simple as possible.
>
> How did all of you deal with this?
>
> Did Windows Installer elevate the priveleges automatically so that you

> didn't need to install the application as administrator?
> --

[Richard]

In article <BAY122-***@phx.gbl>,
"Blair" <***@live.com> writes:

> If you are forced by any other constraint to elevate your setup, make it a
> perMachine installation (especially on platforms without UAC) and install
> the runtime in SxS "shared" mode (either MSM or EXE installer) which will
> allow for the possibility of MSFT servicing of the runtime (which they can't
> do in isolated mode).

What happens if the application is installed per-user and not
per-machine?

I would expect the merge module would still place the shared component
in the shared area and therefore still require admin priveleges, but
the application itself would only be installed for the logged-in user.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

[Blair]

Per-User "managed" installations (not managed as in .net, but managed as in
requires elevation to install, remove, patch, and upgrade) can install the
runtime using the merge modules, as well perform any other operations that
require administrative privileges, but they are kind of the "worst" of all
worlds: they are harder to service (you have to always be the user who
installed them to even discover them, much less manage them), they have to
be installed for each user that wants them but with admin credentials
("What!? I've install that already for John, Sally, and Marge. Why doesn't
it show up for you and I have to install it again?") and in general
represent the worst combination of failing to meet user needs or
expectations.

-----Original Message-----
From: Richard [mailto:***@xmission.com]
Sent: Wednesday, November 11, 2009 7:44 AM
To: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] best way to deploy C++ runtime?


In article <BAY122-***@phx.gbl>,
"Blair" <***@live.com> writes:

> If you are forced by any other constraint to elevate your setup, make it a
> perMachine installation (especially on platforms without UAC) and install
> the runtime in SxS "shared" mode (either MSM or EXE installer) which will
> allow for the possibility of MSFT servicing of the runtime (which they
can't
> do in isolated mode).

What happens if the application is installed per-user and not
per-machine?

I would expect the merge module would still place the shared component
in the shared area and therefore still require admin priveleges, but
the application itself would only be installed for the logged-in user.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

----------------------------------------------------------------------------
--
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

[Richard]

OK, I did a little testing and the results surprised me because the
"working" solution goes against the advice of not including the policy
MSM.

Scenarios are as follows, all on Windows XP SP 3:

- No MSMs, run the vcredist_x86.exe, install my application, my app launches

- Payload MSM, install my application, my app doesn't launch.
=> then run vcredist_x86.exe, my app launches

- Payload MSM + Policy MSM, install my application, my app launches

This seems to imply that I *need* the policy MSM in order to launch my
application. I'm not sure what the policy MSM is doing, but I noticed
that it is also installed by the vcredist_x86.exe installer.

Am I doing something wrong, or do I really need the policy MSM?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

[John L Krupka]

I know the policy msm is required as well. I don't remember what their
purpose is but they have some effect on the Side by Side system. Did you
look in the Event Log when installed with the policy files? I recall that
me a clue as to why they were needed, aside of course from the app not
running.


Richard-45 wrote:
>
>
> OK, I did a little testing and the results surprised me because the
> "working" solution goes against the advice of not including the policy
> MSM.
>
> Scenarios are as follows, all on Windows XP SP 3:
>
> - No MSMs, run the vcredist_x86.exe, install my application, my app
> launches
>
> - Payload MSM, install my application, my app doesn't launch.
> => then run vcredist_x86.exe, my app launches
>
> - Payload MSM + Policy MSM, install my application, my app launches
>
> This seems to imply that I *need* the policy MSM in order to launch my
> application. I'm not sure what the policy MSM is doing, but I noticed
> that it is also installed by the vcredist_x86.exe installer.
>
> Am I doing something wrong, or do I really need the policy MSM?
> --
> "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
> <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
>
> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
>
> ------------------------------------------------------------------------------
> 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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>

--
View this message in context: http://n2.nabble.com/best-way-to-deploy-C-runtime-tp3984609p4001134.html
Sent from the wix-users mailing list archive at Nabble.com.

[Wilson, Phil]

I understand that there's the idea that if you ship code that uses VC++ version x then just use that merge module, forget policy files, your app will work, but then again if the redist does install policy files there is no consistent rule.

The policy files redirect older versions of the Dlls up to the newer ones. If you install the VC 2008 SP1 redist then you install a policy manifest that redirects callers up that new version (instead of to the RTM Dlls). If you don't install the policy files then you get to be the only user of the new VC++ runtime (if you're first at installing it). You can't stop somebody running the redist for SP2 and upgrading you to use the SP2 version anyway.

There may be a hotfix issue in some cases - I haven't tested it all. If you install a merge module containing something like the ATL hotfix and you don't ship a policy file then the existing policy file on the system that redirects people to a specific version of the Dll will point to a Dll that you replaced. If the binding redirect on the system says:

<bindingRedirect oldVersion="8.0.50727.42-8.0.50727.762" newVersion="8.0.50727.762"/>

And you replace 8.0.50727.62 with 8.0.50727.800, then maybe some apps break because that's no longer there.

Richard would have to look at his code's manifest and see what redirection exists on the machine for that particular runtime Dll.

Phil Wilson


-----Original Message-----
From: Richard [mailto:***@xmission.com]
Sent: Friday, November 13, 2009 11:33 AM
To: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] best way to deploy C++ runtime?


OK, I did a little testing and the results surprised me because the
"working" solution goes against the advice of not including the policy
MSM.

Scenarios are as follows, all on Windows XP SP 3:

- No MSMs, run the vcredist_x86.exe, install my application, my app launches

- Payload MSM, install my application, my app doesn't launch.
=> then run vcredist_x86.exe, my app launches

- Payload MSM + Policy MSM, install my application, my app launches

This seems to imply that I *need* the policy MSM in order to launch my
application. I'm not sure what the policy MSM is doing, but I noticed
that it is also installed by the vcredist_x86.exe installer.

Am I doing something wrong, or do I really need the policy MSM?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

------------------------------------------------------------------------------
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-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



*** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at Portland House, Bressenden Place, London, SW1E 5BF (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77. You may contact Invensys plc on [phone] or e-mail ***@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates).

[Richard]

In article <***@INVSFOXXCHMBX02.corp.com>,
"Wilson, Phil" <***@wonderware.com> writes:

> Richard would have to look at his code's manifest and see what
> redirection exists on the machine for that particular runtime Dll.

Hmm.... OK, this is giving me a clue where to look.

I don't have an application manifest that I'm specifying explicitly.
I'm getting whatever Visual Studio 2008 SP 1 with ATL Security Update
decides to generate. Inside the generated exe.intermediate.manifest
file, I find this:

<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC90.CRT'
version='9.0.21022.8' processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>

That tells me that the automatically generated manifest is pointing to
the *old* CRT, which is why I need the policy file to redirect from
the old one to the one in the patched redist.

Now I can explicitly configure the compiler manifest tool to use the
right options, but geez, it feels like a bug in VS.NET here because
they've stopped making the old runtime redist available, but the
compiler is generating references to that old runtime by default.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

[Blair]

Which is exactly the reason so many people ship the policies when they
install the runtimes.

-----Original Message-----
From: Richard [mailto:***@xmission.com]
Sent: Friday, November 13, 2009 5:25 PM
To: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] best way to deploy C++ runtime?


In article
<***@INVSFOXXCHMBX02.corp.com>,
"Wilson, Phil" <***@wonderware.com> writes:

> Richard would have to look at his code's manifest and see what
> redirection exists on the machine for that particular runtime Dll.

Hmm.... OK, this is giving me a clue where to look.

I don't have an application manifest that I'm specifying explicitly.
I'm getting whatever Visual Studio 2008 SP 1 with ATL Security Update
decides to generate. Inside the generated exe.intermediate.manifest
file, I find this:

<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC90.CRT'
version='9.0.21022.8' processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>

That tells me that the automatically generated manifest is pointing to
the *old* CRT, which is why I need the policy file to redirect from
the old one to the one in the patched redist.

Now I can explicitly configure the compiler manifest tool to use the
right options, but geez, it feels like a bug in VS.NET here because
they've stopped making the old runtime redist available, but the
compiler is generating references to that old runtime by default.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

----------------------------------------------------------------------------
--
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

[Richard]

In article <BAY122-***@phx.gbl>,
"Blair" <***@live.com> writes:

> Which is exactly the reason so many people ship the policies when they
> install the runtimes.

Everything I saw describing how to use the merge modules with WiX
recommended against using the policy MSMs.

If I adjust my application manifest to report the correct dependency,
then I shouldn't need the policy MSM. It just feels like its
something they missed in that security update to the runtime.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

[Richard]

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.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

[Rob Hamflett]

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.

[Pally Sandher]

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: [phone]
F: [phone]

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:***@snsys.com]
Sent: 16 November 2009 09:37
To: wix-***@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.