I'm having a similar problem with merge modules I am picking up from another
team. I can't modify those msm's and I'm being forced to add custom actions to
set the system folder properties they use so the files get installed to the
correct place. Mine need to be sequenced before theirs because they are using
the properties that I set. The merging process isn't acting the same as it is
for another product doing the same and I suspect it is because they are using
v2 of wix and I'm using v3. I've moved to
Version 3.0.4923.0 hoping it was a bad version but that version seems to have
it as well.
The msm has the following in their sequence tables
ACTION
SEQUENCE BASE AFTER
CA_ProgramFilesFolder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
CostInitialize 0
CostInitialize
800
These are the calls I'm making
<?define VSDCoreconMsmGuid = "4551CBE5_EB2A_44E8_8F9A_C264DF332068" ?>
<CustomAction Id="Set_ProgramFilesFolder.$(var.VSDCoreconMsmGuid)"
Property="ProgramFilesFolder.$(var.VSDCoreconMsmGuid))"
Value="[ProgramFilesFolder]" />
<InstallExecuteSequence>
<Custom Action="Set_ProgramFilesFolder.$(var.VSDCoreconMsmGuid)"
Overridable="no" Sequence="1" />
</InstallExecuteSequence>
When merged my CA is scheduled down at sequence 12 and the above one is
scheduled at 1 even though costinitialize isn't until 800
It seems that the merging process is not working properly. There are other
actions like appsearch and launchconditions scheduled before costinitialize.
Those are base msi actions that you would think the msm actions should be
scheduled after. My action is setting a property that theirs is using to set.
So basically theirs is run, gets an empty value then mine is ran.
Here is what the table looks like in orca for the actions/sequence prior to
costinitialize. I've highlighted the items shown above in red
ProgramFilesFolder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
1
CommonFilesFolder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
1
WindowsFolder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
1
CommonAppDataFolder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
1
SystemFolder.21022.08.Microsoft_VC90_MFC_x86.RTM.17F6CCF1_663E_333F_9941_1249FE946C34
2
SystemFolder.21022.08.Microsoft_VC90_MFCLOC_x86.RTM.041355E4_1D9A_3127_9B8F_0C95A8B4EB04
3
SystemFolder.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
4
SystemFolder.21022.08.Microsoft_VC90_ATL_x86.RTM.CEC8F2E3_AC9A_357C_BFCB_BFAC37C4AC50
5
ProgramFilesFolder.EE0272F0_1C17_4608_BB9F_B6FF9D5B9825 6
CommonAppDataFolder.EE0272F0_1C17_4608_BB9F_B6FF9D5B9825 6
ProgramMenuFolder.352B874D_7490_4472_A987_71328E788E56 7
ProgramFilesFolder.352B874D_7490_4472_A987_71328E788E56 7
ProgramMenuFolder.3A429435_6A5E_4132_8ECC_57D58F3B8010 8
ProgramFilesFolder.3A429435_6A5E_4132_8ECC_57D58F3B8010 8
ProgramFilesFolder.07298623_FCD5_4637_BE96_DF868BDD83DA 9
SystemFolder.14B856D9_E224_415E_905C_8FF0E9164399 10
CommonFilesFolder.14B856D9_E224_415E_905C_8FF0E9164399 10
CommonAppDataFolder.14B856D9_E224_415E_905C_8FF0E9164399 10
ProgramFilesFolder.14B856D9_E224_415E_905C_8FF0E9164399 10
ProgramMenuFolder.2D6205C1_6B2F_4676_936A_27B1D66A9700 11
ProgramFilesFolder.2D6205C1_6B2F_4676_936A_27B1D66A9700 11
CommonAppDataFolder.2D6205C1_6B2F_4676_936A_27B1D66A9700 11
Set_ProgramFilesFolder.4551CBE5_EB2A_44E8_8F9A_C264DF332068 12
Set_CommonFilesFolder.4551CBE5_EB2A_44E8_8F9A_C264DF332068 13
Set_WindowsFolder.4551CBE5_EB2A_44E8_8F9A_C264DF332068 14
Set_SystemFolder.4551CBE5_EB2A_44E8_8F9A_C264DF332068 15
Set_System16Folder.4551CBE5_EB2A_44E8_8F9A_C264DF332068 16
Set_TempFolder.4551CBE5_EB2A_44E8_8F9A_C264DF332068 17
Set_StartMenuFolder.4551CBE5_EB2A_44E8_8F9A_C264DF332068 18
Set_ProgramMenuFolder.4551CBE5_EB2A_44E8_8F9A_C264DF332068 19
Set_CommonAppDataFolder.4551CBE5_EB2A_44E8_8F9A_C264DF332068 20
Set_AppDataFolder.4551CBE5_EB2A_44E8_8F9A_C264DF332068 21
Set_DesktopFolder.4551CBE5_EB2A_44E8_8F9A_C264DF332068 22
Set_AdminToolsFolder.4551CBE5_EB2A_44E8_8F9A_C264DF332068 23
Set_System64Folder.4551CBE5_EB2A_44E8_8F9A_C264DF332068 24
AppSearch 50
LaunchConditions 51
SET_TARGETDIR 52
ValidateProductID 700
WindowsFolder.21022.08.Microsoft_VC90_ATL_x86.RTM.CEC8F2E3_AC9A_357C_BFCB_BFAC37C4AC50
701
WindowsFolder.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
702
WindowsFolder.21022.08.Microsoft_VC90_MFCLOC_x86.RTM.041355E4_1D9A_3127_9B8F_0C95A8B4EB04
703
WindowsFolder.21022.08.Microsoft_VC90_MFC_x86.RTM.17F6CCF1_663E_333F_9941_1249FE946C34
704
WindowsFolder.21022.08.policy_9_0_Microsoft_VC90_ATL_x86.RTM.A50B7592_50BC_31A9_9E25_32121F451D37
705
WindowsFolder.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
706
WindowsFolder.21022.08.policy_9_0_Microsoft_VC90_MFCLOC_x86.RTM.0390D80A_CD51_37A0_B5C5_C861D417F876
707
WindowsFolder.21022.08.policy_9_0_Microsoft_VC90_MFC_x86.RTM.7F9A85ED_D023_3818_B6DC_A687410206B5
708
CA_ProgramFilesFolder2_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
709
CA_ProgramFilesFolder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
710
CA_CommonFilesFolder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
711
CA_WindowsVolume_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
712
CA_WindowsFolder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
713
CA_SystemFolder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
714
CA_System16Folder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
715
CA_TempFolder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
716
CA_StartMenuFolder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
717
CA_ProgramMenuFolder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
718
CA_CommonAppDataFolder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
719
CA_AppDataFolder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
720
CA_DesktopFolder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
721
CA_AdminToolsFolder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
722
CA_System64Folder_x86.3643236F_FC70_11D3_A536_0090278A1BB8.4551CBE5_EB2A_44E8_8F9A_C264DF332068
723
CostInitialize 800
Thanks,
Lees
-----Original Message-----
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: Thursday, September 25, 2008 1:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Custom Actions from Merge Modules
It's more complicated than that. The problem your hitting in WiX v3 is
actually a feature added in WiX v2 that allows a developer to separate their
authoring into separate "Fragments" and have everything get stitched back
together. In WiX v1 the best you could do was to separate authoring out into
Merge Modules and try to merge everything back together. This
"symbol/reference feature" implemented WiX v2 was what allowed WiX v2 scale to
the needs of Office way back in 2003.
On top of the scalability improvements, that feature has an additional
(usually) desirable feature of informing the developer when a required piece of
the setup (such as an Custom Action definition) is missing. Unfortunately, in
your case, the improper separation of code in the Merge Modules means those
references are broken. As Bob noted, you could switch to .wixlibs and then the
WiX toolset would be able to resolve references. Merge Modules are limiting in
their design here.
It isn't about morals, it's about correctness and limitations in the various
designs (both in MSI and in WiX).
To carry your analogy of editing with Orca to native code, it is not possible
to link a .cpp with code that buried in a compiled DLL (i.e. not code that is
exported from the DLL). The link.exe will fail telling you it can't resolve
reference and will not generate an executable. Now you could probably go in
with a hex editor and make everything work at the assembly/machine code level.
Just like in this case, you can go in and hack at the MSI with Orca but
light.exe won't be able to help you.
Finally, migrating from WiX v1 to WiX v2 is a large undertaking. Migrating
from WiX v2 to WiX v3 is pretty straight forward (and WixCop can help *a lot*).
WiX v1 didn't have half of the concepts that WiX v2/v3 has and was about half
as powerful as WiX v2/v3. I'm sorry it was surprising that there is lot of
work to migrate from WiX v1 to WiX v2/v3 but anyone that lived through the
migration would have told that it wasn't going to be easy.
-----Original Message-----
From: Tina Basinger [mailto:tinabasin...@gmail.com]
Sent: Thursday, September 25, 2008 12:48
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Custom Actions from Merge Modules
It seems to me that Wix is being unsupportive of something that Windows
Installer allows. The InstallExecuteSequence table of an MSI contains
references to both the custom actions defined in the MSI directly as well as
in the merge modules. You can go in and modify this table directly (using
Orca) however you like, and the MSI essentially doesn't know whether an item
in the table was merged in from a merge module or directly by the install.
Thus, in my opinion, Wix is not allowing something that Windows Installer
fully supports, and this seems wrong to me.
I'm not suggesting that it is good design to code things such that a merge
module defines a custom action, and the main install schedules it. I'm just
suggesting that Wix is attempting to force people into a good design, and in
this case i don't appreciate it. It's like you're forcing some sort of
moral standard on me rather than letting me make that decision (and possibly
mistakes) for myself.
Our install is really old and minimal maintenance is only done as needed.
I've just upgraded it from Wix 1.0 to Wix 3.0 (like I said, it's an old
install...), and am running into many issues due to the poor design choices
that were originally made, but were allowed by Wix 1.0. These issues relate
around the fact that our main install can no longer schedule the merge
module custom actions. We have 3 main installs consuming our merge modules,
and some of the merge module actions are scheduled in different orders or
with different conditions (usually based on main install properties) between
the various installs, so I really cannot move the scheduling of these items
into our merge modules. For these, i've pulled the custom action definitions
into a wix fragment so that I can keep the scheduling in the main install.
But then there are other custom actions that I have had to leave defined in
the merge modules and schedule them there because they set merge module
properties. But scheduling these is becoming a problem because the order
depends on other custom actions that are now scheduled by the main install.
It's a mess!
So, as you can see, upgrading to wix 3.0 is giving me a much bigger headache
than I foresaw, which is why I'm a bit perturbed that the wix toolset is
forcing this moral standard upon me, especially since it didn't in the
(very) old days. And yes, our install is obviously very poorly designed
(not by me), but so far it's worked for us, and it's just going to take a
bit more work than I thought to get it working with wix 3.0.
Thanks for listening to me grumble...
-Tina
On Wed, Sep 24, 2008 at 10:29 PM, Bob Arnson <b...@joyofsetup.com> wrote:
> Tina Basinger wrote:
> > Maybe this is not supported any more. Should I be able to have the main
> > installation code schedule a custom action that is defined within a merge
> > module? Any thoughts?
> >
>
> Merge modules are designed to be self-contained, which is why they have
> the modularization GUID attached to their IDs. They should schedule
> their own custom actions. I'm not aware of any way to do what you want
> with WiX, except using .wixlibs instead of .msms.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
