4 replies to this topic

[Uptomyneck]

Hi folks - my first post here but hopefully my question won't have you rolling on the floor laughing

We currently package applications for Windows XP 32bit. Shortly we'll be migrating to Windows 7 64bit.
Will our existing XP packages install on Win7 ?

I understand there will be some remediation work but is there anything that is a complete showstopper?

I've created 64bit packages for Server2003 before and am aware of some differences. My main area of concern is really around the XP to 7 jump.

Thanks in advance.

[Stefan Krueger]

In general, a properly authored msi package should run on Windows 7. A typical cause for problems is custom actions that are defined as "deferred" instead of "deferred without impersonation" which causes them to fail because of permission problems.

[Uptomyneck]

Thanks Stefan. Just a little clarification if you can ?

You are saying that providing custom actions are not an issue a properly authored MSI should run on both XP & Windows 7.

But what about msiexec 5.0 that has features to handle UAC and Restart manager etc ? These would not have been authored into the XP msiexec 3.0 package.

Also, if you create a packages for Windows 7 and then try to install on XP would there not be more problems ?
For example, using the MsiLockPermissionsEx table. This would not work on XP with msiexec 3.0

Considering the above, if the object is to support both XP and Windows 7 systems is it better to create 2 separate packages. One for XP and one for Windows 7 ?

[Stefan Krueger]

In general, you can't use the new features in newer Windows Installer versions. In other words: your setup will behave like on XP.

UAC - you can't mark the msi as "doesn't require admin rights", i.e. per-user installs for non-admin users could be a problem. But typically, your install will require admin rights anyway.

Restart Manager - your setup won't use the improved restart manager, but instead require a reboot at the end (if locked files were encountered), just like on XP.

If your msi contains new tables like MsiLockPermissionsEx these will simply be ignored on older versions of Wndows Installer. If you need advanced lock permissions, you could add a custom action for that purpose (in addition to authoring the MsiLockPermissionsEx table) and condition it to run only on older versions of Windows Installer.

I wouldn't create two separate packages. This could confuse your users, would require additional testing, could become a patching/update nightmare. And what if they install the XP version and then upgrade their OS to Windows 7?

[Uptomyneck]

Thanks for that Stefan. A lot of what you say makes sense regarding the absence of the newer features etc.
I guess the question I should ask myself is what is more important here...the adoption of newer\better technology or the experience of the end user and time taken to deliver.

Release of the OS is centrally managed so its not a problem if users have XP apps but get a new OS - it will be a rebuild or completely new hardware. So no user experience issues.
We have about 5000 existing XP applications. Instead of re mediating these we should just take a leap and create new Win 7 msi's.
I recognize Custom Actions are often unavoidable but using them to set permissions when tables exist is not something I'd adopt - purely because it is more time consuming when errors occur to investigate these packages and actions to see what the last packager has done.

Honestly, I'm leaning towards 2 msi's. I don't want to sacrifice the benefits of msi 5.0 purely because it takes more effort\time. XP will be phased out and the library of applications will fully support msi 5.0 without remediation.
And finally, our company is a little too fond of cmd\batch files i.e. they need a push towards newer tech. And this is an opportunity to do this.

Once again, thanks for your advice.