3

I have a pure InstallScript project, which turns out to be problematic due to this issue. It was temporarily resolved by adding some InstallScript that wipes a particular directory before the new files are installed, which is not ideal. However, this series of forum posts indicates that an InstallScript MSI project or Basic MSI project would greatly simplify the removal of dynamically linked files on upgrade.

Searching the Flexara forums, I find a lot of posts railing against the InstallScript MSI project type, so I'm looking at Basic MSI. Apparently Flexara has a product called Repackager that can convert InstallScript projects to Basic MSI. However, it only comes with IS Premier or Admin Studio, which would mean we have to spend some money. Before I go down that road, I need some indication that this is likely to work.

  • Can any functionality be lost when converting from InstallScript to Basic MSI with the Repackager tool? We have a fair bit of logic in our scripts, including things like this that pass information across several steps of the installation. We also use several InstallShield NT Service Objects, legacy objects I believe I had to install separately from IS2010. Are there any aspects of InstallScript projects the Repackager is known to not handle?
  • If the Repackager isn't going to magically convert the project, is there a guide somewhere that I can follow to do the conversion manually? I have found the InstallShield documentation and forums to be pretty severely lacking.
  • Is there any way the resulting Basic MSI install package will be able to perform upgrade installs on systems where an old (pure InstallScript) version is installed? This would really be a bonus. At this point I'm expecting we'll just be forced to do a full uninstall/reinstall.
Community
  • 1
  • 1
sjohnston
  • 612
  • 5
  • 21

2 Answers2

3

A repackager at best can only capture one instance of the business rules of an install. You can't simply 'convert' your install but rather you redesign it. Ideally you would have an MSI expert review your InstallScript project and identify the pieces that can be eliminated through refactoring to MSI best practices and then rewrite the remaining portions to fit MSI's sequence tables.

If your old uninstall behaves nicely you can write a custom action that removes it. This is easiest if your new product goes to a new installation directory as you eliminate potential file costing issues. If this is not possible and/or your old install doesn't have a properly behaving uninstall then this will become more complicated.

It can also be more complicated if you have configuration data that you want persisted from the old installation context to the new context.

I've done many of these over the years and while it can be very challenging it can also be rewarding as you get to clean up a lot of crud along the way.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
3

I wouldn't recommend the repackager solution for the same reasons Christopher mentions.

A good bridge between your InstallScript project and new Basic MSI project would be to create a new Basic MSI project which uses InstallScript custom actions. With this approach, the MSI engine will manage the non-proprietary aspects of your install, and the legacy InstallScript code can be reused to manage the proprietary aspects of your install.

This gives you the best of both worlds -- a robust Basic MSI package which you have complete contol over (since it wasn't autogenerated by a repackager) PLUS time savings since you don't have to reimplement your InstallScript functions from scratch.

William Leara
  • 10,595
  • 4
  • 36
  • 58
  • 1
    I would caution however that make sure the legacy installscript code that you bring over doesn't turn your MSI into a fragile beast. IMO opinion there isn't any inherently wrong with InstallScript ( others would vehemently disagree with me ) the problem comes when it is misused and abused. – Christopher Painter Mar 05 '11 at 00:58