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

overwriting of nonversioned files


4 replies to this topic

RomanBK

RomanBK
  • Members
  • 2 posts

Posted 13 February 2003 - 15:48

How can I prevent overwriting of .chm help file with his old version ?
I defined a component for .chm help file and designated that file as the key path file of component. This file was included in product "One". Later .chm file was modified and its new version was included in product "Two". If I will installed product "Two" first and after - product "One" on the same
computer with default file versioning rules I will have old version of that help file installed on computer. As far as I understand the "Companion files" mechanism can not be used in this case because .chm file must be the key path file in component and, in contrast, file that is the key path for
its component must not be a companion file. I don't know whether it is possible to customize "REINSTALLMODE" property so that to have correct result and don't overwrite a new versions of versioned files too. May be it possible to have always a fresh versions of a files (versioned and
unversioned, except user data ) on a computer independently of products installation sequence ?

Thanks in advance.

P. S. As far as I understand the Hash table can't help me too.

narapark

narapark
  • Members
  • 18 posts

Posted 19 November 2003 - 16:51

sad.gif

Hi,

did you managed to find a solution for this?
I need to do the same but could not find any info on this so far...

Many thanks.



Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 19 November 2003 - 20:32

It is possible to prevent a setup with a lower version to overwrite a setup with a higher version. To do this you need to use the upgrade table and a special type of custom action. It also needs to be included in the "older setup" for it to "know" not to overwrite a newer setup. In other words if version 1 is already released, it will not check whether a higher version is installed first.

Let me know if it would help you to extend the setups to detect if a higher version is already installed. The procedure to do this is a little bit exotic, and I don't want to write it up unless you think you can use it.

Edited by Glytzhkof, 19 November 2003 - 20:33.

Regards
-Stein Åsmul

narapark

narapark
  • Members
  • 18 posts

Posted 20 November 2003 - 12:24

Hi Glytzhkof

Thank you for the reply!

----------------------------------
>In other words if version 1 is already released, it will not check whether a higher >version is installed first.
----------------------------------
yes... unfortunately the previous software is already released... sad.gif

The files are not versioned and none of the msi rules seem to do what I want to do....how easy it would be the files are versioned!!

How can I make the install not to overwrite the files with newer dates with the files with older dates? Surely I am not the only one with this problem...?

PeterMateja

PeterMateja
  • Members
  • 1 posts

Posted 17 December 2004 - 22:12

We also have this exact same problem. We must install .chm files for all of our products into a shared location (as chm help files must be in the same folder to link to topics between help files...don't get me started...grrr...). So, Product A was released last spring with an older version of a shared .chm file. We are currently trying to release Product B, with an updated version of the help file. When installing Product A on a system with Product B already installed, the Product A installer always overwrites the new help file with the old version. There seems to be no way to fix this problem after the fact.

The 2 methods I've read on the forums to fix this are:
1) Install .chm (and other non-versioned files) as companion files to a versioned file (.dll or .exe).
2) Use the MsiFileHash table. However, I don't think this will work as required. Looking at the verioning rules concerning non-versioned files with file hashes, there's no mention of date comparison within the file hash...only non equality.

And of course the problem with both of these solutions is that since Product A is already released, neither will fix the problem since they require changes to be made to both installers (and no...providing an patch for Product A's installer is not a feasible option.)

At this point, we're looking at writing some custom appside code to Product B that automatically fixes this on first run. That's such a kludgey fix, and shouldn't really even be on the table, but at this point our hand is being forced.

Edited by PeterMateja, 17 December 2004 - 22:13.