1

I have a WiX project making msi which replaces much older installation which was made by a set of scripts which unpacked zip files.

I'd like to specify that certain files in msi must force overwrite already existing non-versioned files from the old installation. Later it wouldn't be a pb as msi to msi update would be an upgrade.

Is it possible to specify on a per-file basis that msi must overwrite old non-msi installed files?

ElDog
  • 1,230
  • 1
  • 10
  • 21
  • It would be easier to just install to a new installation folder? – Stein Åsmul Jul 01 '20 at 15:24
  • @SteinÅsmul No. It is already being installer in many folders, some of which contain legacy components for which changing a folder is not an option. The whole idea is to (partially) replace a very complex and error-prone old procedure for something more controllable. And it is a success already. The most often changed component is now msi which drastically reduced the time to prepare an update and the number of installation errors. – ElDog Jul 02 '20 at 07:06

1 Answers1

1

I will add some links for you and a summary.

Yes, you can overwrite single files by various means and you can even force downgrade files setup-wide, but the latter is terribly dangerous to do (information on dangers in section 4 here).

Ensure Overwrite: This answer describes various measures to always-overwrite files: Ensure file overwriting - with a WiX example. Here is an alternative answer.

  • The use of companion files is what I would recommend.
  • Hacking file versions I do myself sometimes - just to make things work.
  • I prefer to move or rename files to "remove the problem".

See the above links for more on the above "options".

Further information:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • I'm not sure this is an answer to my question. My requirements are quite simple. During the first msi installation there would be already files in the folders I'm installing to. These files don't come from msi, they were manually copied earlier. I just want them to be overwritten. I don't care about their versions (some of them are archaic dlls 10 years old, which versions?), I just want to physically overwrite them and not to get my installation failed. After the msi is installed upgrades will proceed in a "civilized" way, I do it already and see no pb with it. – ElDog Jul 02 '20 at 07:22
  • 1
    The [file overwriting rules](https://learn.microsoft.com/en-us/windows/win32/msi/file-versioning-rules) are very complex with MSI. Please check that link to understand how they work. The remaining links above describe real-world scenarios. – Stein Åsmul Jul 02 '20 at 09:02
  • Reading this article I'd say I need "Versioned Files Win" rule. – ElDog Jul 03 '20 at 09:40
  • The rules are generally to prevent DLL-hell of downgraded, shared files. What we might need is the right to overwrite files by force in folders that your application "owns" - in other words its own installation folder - whereas such behavior would **not** be allowed in shared folders. This to prevent downgrade of shared files, system-wide, but to give you full control of your own files. It is possible to have folders that are shared between your own applications though - so you could have one package downgrade a shared file undesirably by installing older packages after newer ones. – Stein Åsmul Jul 03 '20 at 09:44
  • We now also have the concept of **side-by-side assemblies**. The WinSxS for Win32 files and the GAC for .NET files. Not at all without problems either. Here you can bind to the version of a shared file you need - so you can have a branch for versions **1.x.x** and one for **2.x.x** that are both maintained with backwards compatibility. "Cute story" as I always say when things are nice in theory. *"In theory there should be no difference between practice and theory, but in practice there is"*. Second coming of DLL-hell as your application binds erroneously and security flaws in both branches? – Stein Åsmul Jul 03 '20 at 09:49
  • > What we might need is the right to overwrite files by force in folders that your application "owns" Yes, that's what we need. So... how? :-) – ElDog Jul 03 '20 at 13:47
  • It says in the first two links [1](https://stackoverflow.com/a/54766353/129130), [2](https://stackoverflow.com/questions/60827039/file-of-a-new-component-isnt-installed-because-there-was-an-old-component-with/60854570#60854570). Look for "companion file" and there are other options too. [One more older answer](https://stackoverflow.com/a/1434514/129130) (option 2 there might not work at this point). – Stein Åsmul Jul 03 '20 at 13:51