locked
MSM AnyCPU MSIL ProcessorArchitecture requiring references in ModuleDependency Table RRS feed

  • Question

  • If we consider the fact that the ModuleDependency Table enables a merge or verification tool to ensure that the necessary merge modules are in fact included in the user's installer database.
    http://msdn.microsoft.com/en-us/library/aa370046(v=vs.85).aspx

    If I understand correctly this table has no influence at all on the Windows Installer Engine and its rules during runtime of the installation. It is only used by Installation editors (Orca, InstallShield and so on...) to inform the Setup Engineer of MSM dependencies that are needed.

    I have a situation with one of my Merge Module that contains only AnyCPU DLLs.

    a) My AnyCPU MSM contains 5 DLLs built with the AnyCPU flag.
    For the 5 DLLs the ProcessorArchitecture is MSIL in the MSIAssemblyName table.
    We want AnyCPU support and do not want the requirement of a link in an MSM to impose the requirement to have specific build targets.

    b) My AnyCPU MSM delivers all 5 files in GlobalAssemblyCache (Windows\Assembly location)

    My requirement is to include a reference to another MSM that is not AnyCPU.
    That referenced MSM has a x86 and also a x64 version.
    So I have 2 MSMs to reference to XYZ_x86.msm and XYZ_x64.msm

    QUESTION:
    My MSM containing only AnyCPU dlls how can I reference 2 merge modules one 32-bit and one 64 bit and still be able to keep my MSM AnyCPU meaning it can be included in a 32-bit MSI as well as 64-bit MSI package?

    What I think I can do is to have 2 EXACT copies of my AnyCPU MSM. 

     

     

    MY SOLUTION:
    Create a copy of my MSM and change ONLY the ModuleDependency Table.
    My 2 MSMs will have the Same exact components IDs, Same exact ModuleSignature, Same exact target locations, Same exact files but one will be referencing XYZ_x86.msm and the other referencing XYZ_x64.msm.
    This should not create a problem, it should not break any Windows Installer Rules,

    It would be the same than having multiple products delivering the same MSM which is the goal of creating MSMs.
    (When a MSMs is included in multiple MSIs that is exactly what happens any way.)
    The same exact components, same exact target locations, same exact files are included in multiple MSIs.
    The only difference in both MSMs would only be the ModuleDependency table.

    My AnyCPU_a.MSM that references XYZ_x86.msm will be used by 32-bit MSIs (and possibly 64-bit MSis).
    My AnyCPU_b.MSM that references XYZ_x64.msm will be used by 64-bit MSIs only.

    The only possible problem I foresee is what happens if a 64-bit MSI wants to include both of my MSMs AnyCPU_a.MSM and also AnyCPU_b.MSM. The ModuleDependency Table will only be merge once. This should not really be a major problem anyway because the ModuleDependency Table is only a verification tool.

    The other tables of my MSMs will be merged once as well but all of these tables being exactly the same it is not a problem at all. 

    Comments?

    I tested this approach and found no problems.
    I am inquiring if there is another way to accomplish what we are trying to do.

    Thank you in advance for your help. D. G. Schneider

     

    Wednesday, March 23, 2011 3:52 PM

Answers

  • The recommendation is that you create separate MSI setups for 32-bit and 64-bit setups.

    http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx 


    Phil Wilson
    Wednesday, March 23, 2011 4:51 PM
  • I understand - .NET MSIL code is the exception in the sense that it can run on any platform. Installers generally can't deal with that though, which is one of the reasons two separate MSIs are suggested.  Also, for example, if you have a native x64 app you're installing you want to to use the ProgramFiles64Folder property as the app install folder in the setup project, and others like the CommonFiles64Folder because that's where native code should go, and also are the locations that 64-bit apps retrieve when they ask for special folders ProgramFiles and CommonFiles. The ProgramFilesFolder property will be the ...(x86)... folder on 64-bit systems. You may have to worry about where your setup project's registry entries are (WOW6432 or native). These all accumulate into why separate setup projects are needed.
    Phil Wilson
    Thursday, March 24, 2011 11:13 PM
  • Hi dgschnei,

     

    A 64-bit merge module has any of the characteristics identified in this this topic.

    • The merge module contains at least one component that has been compiled for 64-bit operating systems.
    • The merge module contains no 64-bit components, but is intended for use only with 64-bit Windows Installer packages.

    Merge modules can be used as follows:

    • A 64-bit merge module can be merged into a 64-bit Windows Installer package. The Template Summary properties in the merge module and in the Windows Installer package must be set to the same type of 64-bit processor. A x64 merge module can be merged only into x64 packages and an Intel64 merge module can be merged only into Intel64 packages.
    • A 32-bit merge module can be merged into 32-bit or 64-bit Windows Installer packages.
    • A 64-bit merge module can be merged into a 64-bit package on a 32-bit operating system.

    Adhere to the following when authoring a 64-bit merge module:

    • Use the same general procedure as when authoring 32-bit merge modules. For information, see About Merge Modules and Authoring Merge Modules.
    • You must set the Template Summary property with the Intel64 value if running an Intel64 system. You must set the Template Summary property with the x64 value if running an x64 system. For information see Merge Module Summary Information Stream Reference.
    • When both 32-bit and 64-bit merge modules exist for the same component, it is recommended that the modules have different signatures. This will enable a package to contain both versions of the component.

    http://msdn.microsoft.com/en-us/library/aa372398(v=VS.85).aspx

    http://msdn.microsoft.com/en-us/library/aa367434(v=VS.85).aspx

     

    For the merge rules, we can reference the above.

    PS: I have not found a any cpu option for the Merge Module project Targetplatform in my system, and I also have not found this in documents, there's only three Targetplatform for the Merge Module(x86,x64,Itanium).

    If there's any concern, please feel free to let us know.

    Have a nice day!


    Mike [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.


    Tuesday, March 29, 2011 3:12 PM

All replies

  • The recommendation is that you create separate MSI setups for 32-bit and 64-bit setups.

    http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx 


    Phil Wilson
    Wednesday, March 23, 2011 4:51 PM
  • I understand your reply. Thank you Phil.

    I completly agree the MSM will be in included in separate MSI setups for 32-bit and 64-bit setups.

    It is puzzling because it is a MSM that contains 100% .NET AnyCPU Managed Code.
    We want to be able to install this MSM on both 32-bit and 64-bit platforms (using the corresponding MSI for sure).
    All the files included in the MSM use the "Any CPU" architecture, so it is 32/64-bit agnostic.

    On both 32-bit and 64-bit platforms we will install to c:\windows\assembly\gac_msil

    The only reason I am having a question is because the ModuleDependency Table does not allow me to specify
    dependencies conditionned by the platforms.

    If platforms is 64-bit then reference XYZ_x64.msm
    If platforms is 32-bit then reference XYZ_x86.msm

    I guess I could remove the ModuleDependency and simply put a comment in the MSM stating that the correct dependent MSM is required.
    The Setup Engineer will be the one to decide which dependent MSM he needs.

    D. G. Schneider

    Wednesday, March 23, 2011 5:33 PM
  • I understand - .NET MSIL code is the exception in the sense that it can run on any platform. Installers generally can't deal with that though, which is one of the reasons two separate MSIs are suggested.  Also, for example, if you have a native x64 app you're installing you want to to use the ProgramFiles64Folder property as the app install folder in the setup project, and others like the CommonFiles64Folder because that's where native code should go, and also are the locations that 64-bit apps retrieve when they ask for special folders ProgramFiles and CommonFiles. The ProgramFilesFolder property will be the ...(x86)... folder on 64-bit systems. You may have to worry about where your setup project's registry entries are (WOW6432 or native). These all accumulate into why separate setup projects are needed.
    Phil Wilson
    Thursday, March 24, 2011 11:13 PM
  • Hi dgschnei,

     

    A 64-bit merge module has any of the characteristics identified in this this topic.

    • The merge module contains at least one component that has been compiled for 64-bit operating systems.
    • The merge module contains no 64-bit components, but is intended for use only with 64-bit Windows Installer packages.

    Merge modules can be used as follows:

    • A 64-bit merge module can be merged into a 64-bit Windows Installer package. The Template Summary properties in the merge module and in the Windows Installer package must be set to the same type of 64-bit processor. A x64 merge module can be merged only into x64 packages and an Intel64 merge module can be merged only into Intel64 packages.
    • A 32-bit merge module can be merged into 32-bit or 64-bit Windows Installer packages.
    • A 64-bit merge module can be merged into a 64-bit package on a 32-bit operating system.

    Adhere to the following when authoring a 64-bit merge module:

    • Use the same general procedure as when authoring 32-bit merge modules. For information, see About Merge Modules and Authoring Merge Modules.
    • You must set the Template Summary property with the Intel64 value if running an Intel64 system. You must set the Template Summary property with the x64 value if running an x64 system. For information see Merge Module Summary Information Stream Reference.
    • When both 32-bit and 64-bit merge modules exist for the same component, it is recommended that the modules have different signatures. This will enable a package to contain both versions of the component.

    http://msdn.microsoft.com/en-us/library/aa372398(v=VS.85).aspx

    http://msdn.microsoft.com/en-us/library/aa367434(v=VS.85).aspx

     

    For the merge rules, we can reference the above.

    PS: I have not found a any cpu option for the Merge Module project Targetplatform in my system, and I also have not found this in documents, there's only three Targetplatform for the Merge Module(x86,x64,Itanium).

    If there's any concern, please feel free to let us know.

    Have a nice day!


    Mike [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.


    Tuesday, March 29, 2011 3:12 PM
  • Hi dgschnei,

    I am writing to check the status of the issue on your side. 

    What about this problem now? 

    Would you mind letting us know the result of the suggestions?

     

    Have a nice day!


    Mike [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, April 5, 2011 9:28 AM