1

I'm trying to add a functionality of upgrading my SQL database using one single upgradeScripts.sql file in which I need to hardcode the previous build version and before running the upgrade scripts I need to check If the upgradeScripts.previous build number matches the LocalDB.build number. If don’t match then don’t execute the upgrade scripts. So how can I hardcode the previous build number in WIX itself?

Dale K
  • 25,246
  • 15
  • 42
  • 71
Hemant kumar
  • 11
  • 3

2 Answers2

1

I prefer to create a table in the database itself and use that. It's all too easy to backup/restore a database and install/uninstall/reinstall/upgrade who knows what version for the MSI version to matter. What's important is that the current MSI being installed can create a net new database and migrate a previous schema to the current version. I do this for simple databases that need to be installed on clients silently.

Alternatively, for servers/more complex database, I like to move this out of the installer and into the application. For example Azure DevOps server does this with an Admin Tool. This way your developers have all of their favortite tools available to them without struggling with WiX and MSI.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
-1

Not sure you can do it via wix, but you can store build number in registry and use custom actions to check it:

  1. Add custom action
  2. In that custom action try to read value from registry
  3. If there's some, run your script with values. you can do it from custom action too, or modify script and run it via sql script
  4. After successful installation add new version to registry. You can do it via CA with OnExit="success" - it will run only on successful installation. Here's example with cancel, just change it to success. Or just add custom action after your scrit run. It's easier.
ba-a-aton
  • 574
  • 1
  • 4
  • 14
  • 1
    Why would you need need custom actions to read and write to the registry when MSI and WiX already has this functionality? – Christopher Painter Feb 02 '23 at 21:01
  • depending on version and scope it can be under one of the 4 hives. and option 5 - product not installed. after that you need to modify script an run it. How you'll combine it without CA? not sure that you can modify script inside msi and run it after that. but if yes, it looks very strange too. some of this actions can be done by PS, but running PS it's a CA too (and personaly for me harder to debug) – ba-a-aton Feb 03 '23 at 09:56
  • but in general, best approach is in your answer. there's no need to modify anything if you have step by step migrations – ba-a-aton Feb 03 '23 at 10:01
  • 1
    MSI has a pattern called AppSearch/Reglocator that can read a registry value into a property. You could implment this X number of times. Next MSI has what is called a Set Property Action (Type 51 ) You schedule these with conditions so you say assign 1 to final. assign 2 to final condition final null. And so on. Then MSI has the Registry table that can write a property to the registry. Scripting isn't needed not a best practice. – Christopher Painter Feb 03 '23 at 15:27