Re: vc80_crt deployment failure

Ted

unread,

Nov 14, 2005, 10:50:46 PM11/14/05

to

I think MSI 3.1 is now required on the end user's machine - see some
comments here:

http://blogs.msdn.com/martynl/archive/2005/10/13/480880.aspx

Note this was never revealed as a requirement anywhere.

Ted.

"Antony" <Ant...@discussions.microsoft.com> wrote in message
news:6AF42260-43FA-4E76...@microsoft.com...
> Hi,
>
> Has anyone encountered this problem with the new merge modules?
>
> We've encountered a difference in the RTM msm's from the Beta2 in that an
> extra custom action SxsInstallCA has appeared but is not in the binary
> table.
> This causes msi's built with the release vc80_crt to fail on the missing
> custom action on Windows 2000 installs.
> Did I miss something? Installing the Dot Net framework fixes it but this
> can't be a pre-requisite can it?
>
> Antony
>

Antony

unread,

Nov 15, 2005, 5:12:05 AM11/15/05

to

Thanks Ted,

Indeed it is true the custom action in question is included in V3.1 of MSI.

It would be helpful to know these things. That change must have been known
well before RTM. Still, it works now and MSI3.1 is a 2.5Mb hit rather than
the 23Mb of dotnetfx.

Antony

Ted

unread,

Nov 15, 2005, 9:24:54 AM11/15/05

to

Although, I'm not sure why that is the case, because if I look at the MSM in
Orca it shows the following:

under CustomAction:

Action Source Target
SxsInstallCA SxsUninstallCA CustomAction_SxsMsmInstall
SxsUninstallCA SxsUninstallCA CustomAction_SxsMsmCleanup

and under Binary:
SxsUninstallCA

Notice how the source of the SxsInstallCA action is actually SxsUninstallCA,
which is located in the Binary table.

So I'm not sure what you mean by the SxsInstallCA being included in 3.1.
3.1 seems to be required, but the custom action itself is included in the
MSM (embedded in the SxsUninstallCA binary) . However, I'm not sure why
this custom action (or some other part of the MSM file) actually requires
3.1.

If you find out what functionality of 3.1 is actually required, please let
me know, as I'm not too experienced with MSI. I used to be non-MSI junkie
of InstallShield (at InstallShield community forums I used to post as
tw0001), but gave up on installs a few years ago.

Thanks
Ted.

"Antony" <Ant...@discussions.microsoft.com> wrote in message

news:6A239D11-425F-4C6A...@microsoft.com...

nik...@online.microsoft.com

unread,

Nov 15, 2005, 1:53:21 PM11/15/05

to

This is correct - VS2005 MSMs depend on MSI 3.1. If this is a problem, for example, your product has to have no reboot install on WinXP pre-SP2, you can request a QFE by contacting developer support team on support.microsoft.com.

Thanks,
Nikola
VC++

Ted

unread,

Nov 15, 2005, 7:18:07 PM11/15/05

to

So do you mean that it's a bug that they happen to be dependent on MSI 3.1?
Or was it designed that way from the start.

If it's a bug, will this QFE be rolled into any upcoming service pack?

If using the QFE, will there be any loss of functionality by using MSI 2.0
on Windows 2000/XP/2003?

Is this QFE already built and ready to send to people or does someone still
have to construct it. If so when will be ready?

Thanks
Ted.

<nik...@online.microsoft.com> wrote in message
news:%23S8kaXh...@TK2MSFTNGP15.phx.gbl...

nik...@online.microsoft.com

unread,

Nov 15, 2005, 9:29:17 PM11/15/05

to

It is by design decision. Sorry if I confused you with earlier reply. I just mentioned QFEs because if your company may has proper agreement, then it can request similar changes. If support team contacts us with a request for a change, then we will investigate impact of the change, is it breaking or not, etc and so on. However, you have to bring up this issue with developer support first, then they let us know what should be changed. Another way is to file a report on http://lab.msdn.microsoft.com/productfeedback/, but reports here are triaged as product bugs and may be fixed only in the next product release if fixed.