Switching to MSI installer

Main development forum.

Switching to MSI installer

Postby kimmov » Sun Dec 20, 2009 8:42 pm

As I already once messed up the old style installer with 2.13.9 experimental I think it is time to switch to MSI installer now. The old InnoSetup installer is obviously come to end of its road with runtime installing problems. The only reason I didn't do MSI installer for 2.13.9 was lack of the time. But now I'm ready to find time needed to completely switch to MSI installer.

This means updating documentation, scripts and possibly some other minor tweaks to get it really "production ready".

Tim, do you know if there are something still to be done for the MSI installer itself? Something that really needs to be done before beta-level release?
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Re: Switching to MSI installer

Postby gerundt » Mon Dec 21, 2009 7:48 am

kimmov wrote:Tim, do you know if there are something still to be done for the MSI installer itself? Something that really needs to be done before beta-level release?


The most important things should work! It's only missing things, that make it for the user easier. For example that the setup set the user language, integrate WinMerge to TortoiseCVS and TortoiseSVN.

Here are the todo items, which I save in the WinMerge.wxs file:

  • Tasks
    • Shortcuts
      • Quick Launch
    • Integrate to...
      • TortoiseCVS
      • TortoiseSVN
      • ClearCase
    • Modify Path
  • Don't install 32 bit version von Windows x64
  • Install C++ Runtime files*
  • Separate page for tasks (shortcuts, TortoiseSVN, ...)
  • Install translated readme files
  • Set WinMerge language
  • Mutli-language support

* The setup includes the CRT and MFC modules, so this point seems out-of-day! ;)
gerundt
Site Admin
 
Posts: 192
Joined: Wed Sep 24, 2008 8:47 am
Location: Germany

Re: Switching to MSI installer

Postby kimmov » Mon Dec 21, 2009 8:24 am

Ok, that list doesn't sound bad at all.

Indeed I think we need to think what we even want to include to the MSI installer. Keeping in mind that MSI installer can be run remotely by the administrator. So 1:1 feature parity with InnoSetup installer doesn't even make sense.

For example I'd rather would see WinMerge checking possible integrations and asking them at first startup. There we'd have a lot more control and possibilities to do it than in installer.
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Re: Switching to MSI installer

Postby gerundt » Mon Dec 21, 2009 12:48 pm

kimmov wrote:For example I'd rather would see WinMerge checking possible integrations and asking them at first startup. There we'd have a lot more control and possibilities to do it than in installer.


This would be also good for users, who use the ZIP files and not the setup!
gerundt
Site Admin
 
Posts: 192
Joined: Wed Sep 24, 2008 8:47 am
Location: Germany

Re: Switching to MSI installer

Postby kimmov » Mon Dec 21, 2009 1:34 pm

gerundt wrote:
kimmov wrote:For example I'd rather would see WinMerge checking possible integrations and asking them at first startup. There we'd have a lot more control and possibilities to do it than in installer.

This would be also good for users, who use the ZIP files and not the setup!

Exactly!
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Re: Switching to MSI installer

Postby kimmov » Mon Dec 21, 2009 6:23 pm

I just compiled MSI installer from SVN trunk. It succeeded but there were 118 warning(s) during the installer build. Are all those harmless or something worth looking at?
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Re: Switching to MSI installer

Postby gerundt » Mon Dec 21, 2009 8:21 pm

kimmov wrote:I just compiled MSI installer from SVN trunk. It succeeded but there were 118 warning(s) during the installer build. Are all those harmless or something worth looking at?


This must be the warnings from the CRT and MFC modules and can ignored:

http://blogs.msdn.com/astebner/archive/2007/02/13/building-an-msi-using-wix-v3-0-that-includes-the-vc-8-0-runtime-merge-modules.aspx wrote:When building an MSI that consumes the VC 8.0 runtime MSMs using Votive v3.0 in Visual Studio 2005, you may see several of the following types of warnings in your build output:

  • WixProject1.wxs(10,0): Warning LGHT1055: The InstallExecuteSequence table contains an action 'SxsInstallCA' which cannot be merged from the merge module 'c:\Program Files\Common Files\Merge Modules\policy_8_0_Microsoft_VC80_ATL_x86.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module.
  • light.exe(0,0): Warning LGHT1076: ICE03: String overflow (greater than length permitted in column); Table: Component, Column: KeyPath, Key(s): downlevel_manifest.8.0.50727.762.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
  • light.exe(0,0): Warning LGHT1076: ICE30: The target file 'ansiatl.dll|ATL80.dll' might be installed in '[SystemFolder]' by two different conditionalized components on an LFN system: 'ansi_atl80.97F81AF1_0E47_DC99_FF1F_C8B3B9A1E18E' and 'nosxs.97F81AF1_0E47_DC99_FF1F_C8B3B9A1E18E'. If the conditions are not mutually exclusive, this will break the component reference counting system.
  • light.exe(0,0): Warning LGHT1076: ICE82: This action SystemFolder.97F81AF1_0E47_DC99_FF1F_C8B3B9A1E18E has duplicate sequence number 6 in the table InstallExecuteSequence
  • light.exe(0,0): Warning LGHT1076: ICE83: The keypath for Global Win32 SXS Assembly (Component_=uplevel.66332652_9C28_58B1_FF1F_C8B3B9A1E18E) SHOULD NOT be it's manifest file for assemblies other than Win32 Policy assemblies
    The first type of warning indicates that actions with the same name exist in multiple merge modules. Windows Installer requires unique action names, and when attempting to merge MSMs that contain multiple actions with the same name, Windows Installer will exclude all but the first action. In this case, the exact same SxsInstallCA and SxsUninstallCA actions exist in all of the VC 8.0 runtime MSMs, and so all but the first ones are excluded from the merging process. However, all of these actions are identical and execute the same code behind the scenes, so it is safe to ignore this type of warning because you will not be losing any required functionality during the merge process.

The second type of warning indicates that some identifiers are longer than the maximum values specified in the _Validation table of the MSI. The documentation for ICE03 indicates that Windows Installer does not internally limit the column width to the specified value, so these warnings can be safely ignored.

The third type of warning helps prevent authoring different components that install the same files to the same destination folder (which would violate Windows Installer component rules). However, in the case of these VC 8.0 MSMs, the components have conditions that are mutually exclusive (Version9x and VersionNT < 501) so the component rules will not be violated and these warnings can be safely ignored.

The fourth type of warning indicates that actions contain duplicate sequence numbers in the InstallExecuteSequence table. When actions have duplicate sequence numbers, there is no guarantee about what order they will be run in. However, in this case, the actions have no order dependencies and it is safe to ignore these warnings as well.

The fifth type of warning helps prevent authoring incorrect keypath files for Win32 global assemblies that are installed to the WinSxS component store. This warning indicates that they keypath should not be a manifest file unless the assembly is a Win32 policy assembly. In this case, the assembly is a Win32 policy assembly, so these warnings can also be safely ignored.

Building an MSI using WiX v3.0 that includes the VC 8.0 runtime merge modules
gerundt
Site Admin
 
Posts: 192
Joined: Wed Sep 24, 2008 8:47 am
Location: Germany

Re: Switching to MSI installer

Postby kimmov » Mon Dec 28, 2009 11:52 am

I don't see anything in your TODO-list that would be mandatory for working installer. So I think we'll do the switch NOW. Meaning MSI installer will be our main installer for next experimental/beta releases.

One thing to keep in mind with MSI installer is it really should work as "silent" (remote) installer too so it should not do too much configuration work. So we need to move obvious configuration work from installer to executable configuration.

This is very obvious for version control integration. Users might install SVN after installing WinMerge and currently they have to run installer again to make integration work!

I'll look at expanding version control configuration options to include TortoiseSVN etc.
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Re: Switching to MSI installer

Postby kimmov » Mon Dec 28, 2009 7:25 pm

Forgot one thing... What is the status of -X64 MSI installer? Has anyone build and tested it?

If not then we need to release also -X64 MSI installer ASAP for people to test. I don't have -X64 Windows to test at the moment.
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Re: Switching to MSI installer

Postby kimmov » Mon Dec 28, 2009 7:35 pm

Hmm. Just tried to build X64 MSI installer from folder I used for 2.13.10 experimental release (all files compiled) and it failed. Because it tried to find files from Build\x64-folder. Which of course doesn't exist.

How should we proceed with X64 MSI installer? We could:
  • pack 64-bit versions of all components
  • pack x86 versions of other files than ShellExtensionX64.dll

Couple of people have (me and Takashi) have even build 64-bit versions of our other components. I once even tried them in X64 Windows and they looked to be working. But otherwise it is very much unknown if they even start when build from current sources. So using x86 versions is the safe choice.

OTOH we need to switch to X64 versions in future, no question about that. And perhaps now would be a good time to start really pushing these X64 versions for people to test...
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Next

Return to Developers

Who is online

Users browsing this forum: No registered users and 1 guest

cron