7

I have an installshield installer for my application. Now I create a minor upgrade for the application and some of the files in some of my components are changed. Unfortunately after the minor upgrade the files are not replaced but are left with their old contents. These are text files so it is very easy to verify that. I have also explicitly checked always overwrite in the properties for each of the files I try to overwrite during the upgrade.

I am tired of creating custom actions to do what installshield is supposed to do. Do you have any idea why this is happening and how can I force installshield to overwrite these files?

I am using installshield 2008 and really, really, really wished I had an option to change that.

Ivaylo Strandjev
  • 69,226
  • 18
  • 123
  • 176
  • Have you read the answer? – Ivaylo Strandjev Nov 13 '13 at 08:34
  • Yeah, Firstly I try the `Always Overwrite` for the target file. But It doesn't work until I restart my computer . And I think the bigest problem to me now is I can't find any good reads to understand all the stuff how to work together. like Christopher Painter said `this is a training issue not a tools issue`. So I hope you can share some with me. thanks. – Joe.wang Nov 13 '13 at 09:32

2 Answers2

1

Not to be rude, but this is a training issue not a tools issue. Windows Installer, the underlying technology, is extremely explicit in how it operates with regard to the Component Rules and the File Versioning Rules. If it's not working it's because you've implemented it wrong. If you are writing custom actions to get around it, that clearly demonstrates you do not understand what you are doing and are creating hacks to circumvent MSI.

Now I don't have a copy of your FOO.msi (v1) and FOO.msi (v1.1) or the installer log from the upgrade so your question is unanswerable beyond giving you advice to research such topics as what components, keyfiles and companion files are, how file costing / versioning works, how major and minor upgrades work and then applying that knowledge to your own installer.

Yes, this is obscure, often pedantic stuff. But it's at the core of how MSI works and you really need to understand it. Once you do, it gets much, much easier. Trust me, I've been there.

thekbb
  • 7,668
  • 1
  • 36
  • 61
Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • I have a component that has 4 files in it, all are text files and all install into the same target folder. I have indicated one of them as key file. All of them have their last modified date way newer than the files installed on the system. Still none of the files is replaced during upgrade. According to the rules these files should get replaced, right? Or is there an exception? – Ivaylo Strandjev Jan 31 '13 at 16:09
  • 1
    The rules don't care about the datetime of the file in the installer. They care about the creation datetime and modification datetime of the file already installed. The evaluation is based on the keyfile and all companion files will follow. See: http://msdn.microsoft.com/en-us/library/windows/desktop/aa370531(v=vs.85).aspx – Christopher Painter Jan 31 '13 at 16:26
  • I got it. The last modify and the create data/time of the key files are the same, but still files are not replaced. – Ivaylo Strandjev Jan 31 '13 at 16:45
  • Can you post a log to pastebin or similar? – Christopher Painter Jan 31 '13 at 16:52
  • I am afraid my confidentiality agreement will not allow me to. The only lines that mention the components at all in the log are of the sort: `MSI (s) (6C:20) [18:06:33:962]: Component: AllOtherFiles; Installed: Local; Request: Null; Action: Null` – Ivaylo Strandjev Jan 31 '13 at 16:57
  • That means it's decided not to reinstall that component. I can't tell you more without more information. – Christopher Painter Jan 31 '13 at 17:01
  • 1
    I realize you can not do much more with the information I give you. Thank you for your time and your help. I will give you +1 but will not accept your answer as I will try to figure out what is going on here. If I manage to solve the problem I will post the solution as an answer. Thank you again. – Ivaylo Strandjev Feb 01 '13 at 08:53
  • I consulted some wise guys hitting similar problems we struggled for a long while and in the end our opinions matched on thinking this was an issue with installshield 2008. Their advice was to write custom action for this and that's what I did. I will try to escape this hellish thing it really is full of bugs. Anyways thank you for the help and the links. Though they did not help here, surely they will in future. – Ivaylo Strandjev Feb 07 '13 at 16:40
  • 2
    The only blame you could have with InstallShield is that they dumb down MSI development and try to abstract the underlying details. Otherwise I can't agree with your assessment or resolution. Good luck. – Christopher Painter Feb 07 '13 at 16:43
  • Classic StackOverflow. Don't answer just rant. – tmj Feb 17 '16 at 11:39
  • The rant comes from the fact that he's openly blaming the tool for not doing what it "is supposed to do" and wishing he could change tools. Changing tools wouldn't change the underlying behavior of MSI. BTW, I suspect my tough love helped because he did eventually accept the answer many months later. – Christopher Painter Feb 17 '16 at 11:47
0

I just experienced a similar issue. Even though I changed the version of the file in AssemblyInfo.cs, Install Shield LE did not pick up the new compiled file. It seemed I had to actually open the "Files" menu in "Specify Application Data" before building the solution.

detoor
  • 1