1

I created an MSP patch file using WiX Pyro(using purely WiX toolset). But it seems that created MSP file doesn't include files changed in content but not changed in version number. As I think, most of those files are not actually changed in main content but just rebuilt by Visual Studio. So, it may be desirable behavior that Pyro does.

But my customer asked me why files installed by the latest MSI and files updated by MSP patch are different. So, I want to know there is any way to include those files into MSP patch, or can I tell my customer that those two file sets(the latest MSI, old MSI + MSP) are the same so you can use the product safely? (Of course, I think my file version management is pretty poor and not systematic, but MSI's version rules feel too strict and somewhat inflexible to me.)

David Johns
  • 1,201
  • 5
  • 15
  • 34
  • Perhaps you can set up Visual Studio to auto-increment the last version number (build number) of each assembly? 1.0.0.* or something like that. – Stein Åsmul Jun 12 '14 at 20:18

1 Answers1

2

The Windows Installer file update rules are what they are, and I don't think you're going to get them changed. The standard rule is that you tell Windows the file is updated by incrementing the version, and then at install time a higher version will replace a lower version. That's the reason tools that generate patches also use the version rule - why should they include files that haven't got a higher version? Service packs, patches, hotfixes etc all work based on file versions.

If you want to use whatever file versions you like, then stop using patches and do a major upgrade that does a RemoveExistingProducts early so you get the equivalent of an uninstall of all the old files followed by an install of all the new ones.

By the way, if these are managed code files and you believe that incremnting the file version means incrementing the assemblyversion, then use AssemblyFileVersion to increment the file version and leave assembly version alone.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • Phil, would REINSTALLMODE=emus work? http://msdn.microsoft.com/en-us/library/aa371182(v=vs.85).aspx. I think it would, but not sure if I would recommend this approach - probably too error prone with default command line being omus unless the patch is wrapped in a patch.exe featuring the default emus REINSTALLMODE? – Stein Åsmul Jun 12 '14 at 20:06
  • Probably better to auto-increment the assembly build version number. Not sure if file replacement works with 3 digits only - like the upgrade table and ProductVersion does. – Stein Åsmul Jun 12 '14 at 20:19
  • OK, then there is no way to bypass msi version rule when creating msp, right? – David Johns Jun 13 '14 at 02:22
  • The basic problem is that version file updates are based on incrementing file versions. A lot of tools depend on that and don't bother including the file. This is one of those cases where nobody can give you a good answer because nobody does this. Patches work based on versions. Downgrading versions is safe only with a major upgrade. I've seen people force downgrade file versions and get into all kinds of problems, such as downgrading Microsoft security fixes by forcing old versions on the system, forgetting that every file gets downgraded. – PhilDW Jun 13 '14 at 18:25