2

I have a msi component which deploys a file MyFile.dll. I have a test machine in which my product already deployed MyFile.dll, which has version 09.99.99.99.

Now I'm writing a major upgrade which will deploy a new version of MyFile.dll with version 05.23.76.123. After execution on the test machine, MyFilee.dll is removed... I need to change or repair to correctly deploy it.

How can I force the deployment of MyFile.dll regardless of its injected version number?

PS: This is happening on our test machines only. The product we delivered to our users has files with version numbers consistent with release history.

Brainless
  • 1,522
  • 1
  • 16
  • 30

3 Answers3

1

There are several ways in Windows Installer to do this but they all have their complications. IMO I would just rebuild the same source code as the old DLL but with a newer higher version and keep it simple.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • I just tried that. It looks that we cannot inject higher file versions. And I just had a meeting with my team where we concluded that it would be better to have real version number for our tests rather than dummy values... – Brainless Jun 29 '15 at 13:25
  • Can we just change the component guids of each corresponding file? I think it should be ok since each of our upgrade is a major upgrade. – Brainless Jun 29 '15 at 13:26
  • Chaging guids for a component with the same keyfile would be a component rule violation. Major upgrades can work depending on where RemoveExistingProducts is scheduled. Some possible failure modes are no DLL gets installed because MSI saw a newer version installed and choose not to install the older DLL and then the upgrade removed the old DLL. It takes an understanding of file costing and upgrade scenarios to solve this. Easiest solution is to make MSI happy and rebuild the DLL with a newer version #. – Christopher Painter Jun 29 '15 at 14:08
  • If it's literally just one Dll then open the binary Dll file (open as file) with Visual Studio, and go change the file version in the verrsion resource. – PhilDW Jun 29 '15 at 19:05
  • I never said to use a "dummy" version. This gets into the areas of build / release / cm practices and depends a lot on your environment. I know in my environment I would just revert the changeset in TFS and kick off a new build, do a major upgrade and be done with it. – Christopher Painter Jun 29 '15 at 20:14
1

This is perfectly possible. As said here, you may specify the REINSTALLMODE property and set it to "amus" or "dmus" depending on whether you want to always overwrite files or simply overwrite files with different version:

<Wix ...>
  <Product ...>
    <Property Id="REINSTALLMODE" Value="amus" />

Note that you'll get this warning when compiling your installer though: warning LGHT1076: ICE40: REINSTALLMODE is defined in the Property table. This may cause difficulties.

Community
  • 1
  • 1
Gyum Fox
  • 3,287
  • 2
  • 41
  • 71
0

Downgrading a file isn't really straightforward and has issues. As pointed out earlier, you can change the component GUIDs and get this to work. However, it really depends on where your RemoveExistingProducts is sequenced. If its sequenced at a point where the older product is removed and the newer product is installed, then it might work.

There is not really a straight forward and documented way. All the available options are just hacks.

Is this just for your test environment? If yes, then you could use REINSTALLMODE="amus" in the property table and achieve what you are looking to. However, this is just for your testing and is not advised to be suggested to your end users.

Regards, Kiran Hegde

Kiran Hegde
  • 680
  • 4
  • 14
  • We cannot change the component GUIDs without changing the each deployed filenames. As Chris pointed out, "Chaging guids for a component with the same keyfile would be a component rule violation."... – Brainless Jul 07 '15 at 06:12
  • 1
    Well, i agree its a violation of windows installer component rules. However, that violation will be in the picture when "RemoveExistingProducts" is sequenced at the very end ie. the newer product is installed as well as the older product is installed followed by an uninstall of the older product. If the upgrade is carried out in a way such that the older product is uninstalled followed by an install of the newer product, then you do not have a violation of the rules here. Because, you dont have two products instaling to the same location with different component GUIDS. – Kiran Hegde Jul 07 '15 at 11:27