Community Forums
Page 4 of 4 FirstFirst ... 234
Results 16 to 19 of 19

Thread: Minor Upgrade not replacing files.

  1. #16
    Join Date
    Jan 2003

    Arrow More than 1200 hits !!!

    The different script versions were downloaded more than 1200 times ! Wow, thanks for your confidence !

    Note, use the latest version here : findinstallfilesupdated.rul (37.4 KB) !

    My company 'Not' release products 'So', 'Really', 'Very', ... with plug-ins 'Fun', 'Great', ...

  2. #17
    Join Date
    Jan 2003

    Exclamation Interresting reading !

    Checkout this page, especially Table 1 on the third quarter :

    My company 'Not' release products 'So', 'Really', 'Very', ... with plug-ins 'Fun', 'Great', ...

  3. #18
    Join Date
    Jan 2003

    Our install script have finally been deprecated !!!

    Hello people around there, as we have switched to InnoSetup 1.5 years back, here's the last InstallScript version we used up to the very lasting InstallShield based releases. This version contains several tricks and tweaks I found out during my journey aboard InstallShield experience, which is several man-month worth !!! I removed all 'sensible' parts that may put the safety of our install in danger, but left some unimportant specific things so that newbies could get a look at how things are and have to be done.

    Well, this script is fully working (maybe some things have been broken when I removed some parts of the script for obvious reasons) and includes all of my little deamon-helpers ! From ReplaceString (which is not part of the basic InstallScript function set) to FinInstallFiles (not part of the basic InstallScript function set either) and all the LOG_ system I implemented to superseed faulty InstallScript system (and produce readable and well structured TXT output).

    Anyway, I hope this script will definitively gives you full working BASIC installation (I never tried too much advanced features of InstallShield as it already fails on the most obvious ones) without upgrade headaches I had in the past. The logic sequence is pretty classic, so I think it should be used in the most variety of installation scenario.

    A final note to tell you that all the upgrade/replace file/... mess is just non-existant in InnoSetup. And the 218 KB InstallScript (a VB/C/whatever mix of language) was fully ported into a 68 KB InnoScript (full object-oriented Pascal) and with more functionalities. Of course I had to recode some deamon-helpers lacking in InnoSetup, but most important I had dropped the whole FindInstallFile and LOG_ stuff as it works well natively. This helps alot !

    But hell, I'm not here to do some Inno advertising here, and in facts I just do not, I'm just telling you coders some raw numbers to compare. InstallShield, once fully reworked with my script was of a precious help. InstallShield works for many people (otherwise it wouldn't be so widely used). I just had to go further without having to pay for every upgrade and repay for every compatible language pack. And InnoSetup do it all from start...

    Well, I wish you a very succesfull installation with the help of my legacy script, I had 'fun' writing it, and I'm pretty proud of its reliability and effectiveness. Just put your code in the place I removed mine, and overwrite the last remaining bits of specific code you'll find that is obviously NOT from the main installation logic flow.

    Good luck coders, may the courage be with you all !


    PS : Comments are in french, sorry for non-natives or non-speakers...
    Attached Files Attached Files
    Last edited by Kochise; 09-21-2006 at 04:03 AM. Reason: Script file was not added at first (.rul extension rejected)
    My company 'Not' release products 'So', 'Really', 'Very', ... with plug-ins 'Fun', 'Great', ...

  4. #19
    Join Date
    Apr 2017

    Wow This worked for me thanks... IN Spring 2012, I chose "Always Overwrite" option.

    Quote Originally Posted by Kochise View Post
    I'm currently experiencing the same problem... Obviously, I'm far from being the only one having such trouble to get new files replacing older ones during a minor upgrade. It have of 'upgrade' only the minor attribute !!! To get an idea of the mess, just search for 'minor upgrade replace file' on the forum...

    To get a successful living with these f***ing minor upgrades, you've to know first how things are managed :

    To identify a product (*NOT* it's version/build revision/patch/whatever) :

    -Product Name (Description\General Information\Product Proprieties)
    -Product Code (Description\General Information\Product Proprieties)
    -Upgrade Code (Description\General Information\Product Proprieties)

    To identify a version/build revision/patch/whatever :

    -Product Version (Description\General Information\Product Proprieties)
    -Package Code (Description\General Information\Summary Information Stream)

    So, beware not to make mistakes : There is your product ID and your product VERSION splitted in two disctinct locations !

    When I do a minor upgrade, don't change ANYTHING to the product ID otherwise it will be found being a new product -> MAJOR UPGRADE !!!

    Just change the Product version and the package code. To manage the product version, the best is to set it to the date of the install compilation (very nice for beta testing) : for instance, today is Tuesday 11 May 2004 -> product version is 2.04.0511 where the 2 is for the millenium, 04 for the year, then the month and the day !

    So day after day, it ensure a product version greater from the previous one. This product version ONLY affect the installer, not your REAL product version, which is located deep inside the EXE file (file version or else, that's your problem to manage) !

    OK, the reminder :

    To get a nice working minor upgrade, just change the product version and the package code, don't create any entry in the Media\Upgrades table, nor fill the Media\Releases\Product Configuration 1\Release x\Previous Package path !

    Windows Installer MUST only rely on the product version you provide, it MUSN'T find anything else that may give it another clues of the packages differences !!!

    Now you made these things nicely, you provide your new setup project new files, compile the setup/upgrade package, and run it on a previously installed product (different product version and package code), the result is :

    EXE, DLL files and else are not replaced, but text files, databases and else yes ! Windows Installer 2.0 fitted with InstallShield 8/9 now check the file version too much carefully, and even miss it sometimes even if file version is greater than the one installed !!!

    The two workaround I tested sucessfully, Both are dirty tricks that make things work utterly fine :

    Delete the EXE, DLL, ... files on minor upgrade :

    Usig the InstallScript, instanciate the OnResumeUIBefore event and write the following code

    // --- OnResumeUIBefore() --- //
    function OnResumeUIBefore()
      STRING szTitle, szMsg;
      NUMBER nvResult;
      STRING svSrcOldFile, svSrcOldFileExt;
      NUMBER nvResultOldFile;
      STRING svProgram, svCmdLine, svMessage;
      LIST listKeyHklmSoftBayoItemsID;
       szTitle = SdLoadString(ISWI_RESUMEUI_TITLE);
       szMsg   = SdLoadString(ISWI_RESUMEUI_MSG);
      nvResult = SdPatchWelcome(szTitle, szMsg);
      if(nvResult == BACK) then
        goto Dlg_SdResumeWelcome;
      // Animation
      SetStatusWindow(0, "");
      StatusUpdate(ON, 100);
      // Test if executable binary file
      nvResultOldFile = FindAllFiles(INSTALLDIR, "*.*", svSrcOldFile, RESET);
      while(nvResultOldFile == 0)
        ParsePath(svSrcOldFileExt, svSrcOldFile, EXTENSION_ONLY);
        if(  (svSrcOldFileExt == "scr")
          || (svSrcOldFileExt == "com")
          || (svSrcOldFileExt == "exe")
          || (svSrcOldFileExt == "dll")) then
          LOG_ADD_STREAM("File:Delete", svSrcOldFile);
          // Make sure the file will be deleted
          DeleteFile(svSrcOldFile); // Delete the unuseful file
        nvResultOldFile = FindAllFiles(INSTALLDIR, "*.*", svSrcOldFile, CONTINUE);
      nvResultOldFile = FindAllFiles(INSTALLDIR, "*.*", svSrcOldFile, CANCEL);
    Before the minor upgrade is applied, the EXE (binary executable) files will be first deleted. So, as these are missing, they will be surely and without a doubt replaced by the new version provided in the minor upgrade !

    The second version don't needs such a file managing/deleting, but is as tricky !

    Force file version check to be greater :

    As Windows Installer often fails to check the file version between the new file and the currently installed file, help this poor coded Windows Installer by providing it a known greater file version. For this, select the Application Data\Files and Folders view. Then, for EACH file (especialy binary executable files such EXE, DLL, ...), do a right click\Properties, uncheck Use system attributes and select version to (provided the curren,t file version is lesser than

    In general, put a VERY big file version number to be sure the file will be matched as newer than the current so that WIndows Installer will finally do its job and replace the files ! Make sure your file version will never reach this fake version number.

    Once installed though, the file versions are *NOT* overwritten with the faked version, so your new EXE will have this version, and *NOT* !

    Job done !


    PS : I know, a single batch file would have done the job in seconds !
    Wow This worked for me thanks... IN Spring 2012, I chose "Always Overwrite" option.

Page 4 of 4 FirstFirst ... 234

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts