Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Upgrade Method


8 replies to this topic

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 07 September 2001 - 21:41

Basically our product is comprised of .exe's, system files, and databases.  Using Express, our upgrade method was basically the same build as our Full install minus one database, I'll call info.mdb, which holds end user application information.

I would simply exclude this file from the upgrade build, change the Product code and add the Upgrade code information to the Upgrade table via Orca.

We have since migrated to Pro - Windows Installer 2.03.  Is this method of upgrading OK?  If so, should I (do I have to) change the Package code as well?

As always, Thanks!!!

(Edited by Superfreak3 at 9:42 pm on Sep. 7, 2001)


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 07 September 2001 - 21:43

I'm not sure that I exactly understand what you are doing, but you should change the package code all the time, for each build.

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 07 September 2001 - 21:52

Lets say the full install consists of files A, B, and C.  A is an .exe, B is a registered ocx, and C is the info.mdb.  

The upgrade would consist of A, and B, but NOT C.  I would then change the Product ID and add the upgrade code to the upgrade table.  Basically, instead of just updating files that have changed from a previous release, we fold them into the full build minus the info.mdb.  This was done mainly because we were unfamiliar with the upgrade/patch concepts.

If it has become a bit clear, which it probably hasn't, do you foresee any problems with continuing our customary procedure?


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 07 September 2001 - 22:04

So this seems to be a major upgrade, which will detect the older product and remove it. I would expect it to delete all three files A, B and C, and then install the new versions of files A and B. Unless you have marked file C as permanent, I expect that it will be deleted.

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 10 September 2001 - 13:20

File C is marked as premanent, never overwrite.  Now what do you think.  Is our current method OK?

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 10 September 2001 - 16:47

Yes, I would expect that it would replace A and B as intended, and leave C as is.

Tim Byng

Tim Byng
  • Members
  • 1 posts

Posted 14 September 2001 - 20:37

I haven't created many packages, but from what I understand from Microsoft's documentation, you may run across a few problems down the road if you follow this method.  Someone please correct me if I'm wrong.

I'm assuming you're creating a major upgrade (since the product code is being changed).  Please note, as Stefan said, the package code should always be changed.

Using your example, component C was marked permanent.  When you apply the major upgrade, it will leave that file there during the uninstall of the previous version.  However, component C is not part of the new cached install.  The original cache information from component C would have been removed when the upgrade uninstalled the old version (even though the file remains).  If, for some reason, an application or the installer itself needs to get information about component C, I don't believe it will work.  For example, let's say you would like to get the path location of component C using the Windows Installer automation; it will not be able retrieve information about this component since it is not part of this package.  Also, if for some reason you try to repair or reinstall the package (let's say file C was corrupt or deleted), it will not reinstall this file.

If the user is installing your app on a clean computer, you are forcing the user to first install the original package, and then install the upgrade.  If you include component C in the upgrade package, the user could use the upgrade package as a full install, rather than having to use the original package followed by the upgrade package.

Since the file is a database, you probably don't want this file to be overwritten with the empty database.  You could probably just use some sort of condition that will allow you to bypass installing this file if it already exists.

Again, I'm no expert by any means, so I can't really say for sure.  I hope to get some feedback about this issue as well.


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 14 September 2001 - 22:01

Tim,

you're correct. Windows Installer would no longer know about the database file, would not repair it and not delete it on uninstall. It would become a orphan.

And indeed you'd have to install both packages, because the update doesn't include the database.

If all you want to achive is not overwrite a dtabase file where user data have een stored: that's the defasult behaviour. MSI won't overwrite versionless files if their modify date (last saved) is more recent than the create date (install date).

However I guess that Superfreak wants to reduce the file size of the update. Another way to achieve this would be a patch.


Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 17 September 2001 - 19:41

Here is a redesign of our product.  What does anyone think?  We basically made the Typical install our full install and our upgrade is installed by the Custom install mechanism.  

If the user chooses the upgrade or Custom install, all features except that containing the info.mdb are installed via AddLocal.

What effect does this have (good/bad) on our current method of upgrading.