One relatively simple approach that I have used for a similar SQL CE app is to distribute with the update a list of SQL statements that contain the cumulative updates to the schema since the first version of the schema that was initially distributed. The final SQL statement in the list will update a row in a lookup table so that the version number of the schema will be the same as the release. The SQL statements can be distributed either as a file or as a resource in the application.

UPDATE lookupTable
SET value = 'alarm.wav'
WHERE lookupType = 'sounds' AND lookupId = 'soundFile' AND value = 'test.wav';

ALTER TABLE Users DROP CONSTRAINT UQ__userEmail__00000000000000E0;

UPDATE lookupTable
SET value = '2.8.0.6'
WHERE lookupType = 'version' AND lookupId = 'DataModelVersion';

Then each time the program runs it can check the value of the version number of the program versus that of the current schema and if the schema is not the same then it will run the latest schema file to do the schema changes and then update the schema version, e.g.

if (!Application.ProductVersion.Equals(schemaVersion)) {
    Schema.UpgradeDatabase(Schema.GetDbConnectionString(), upgradeFile);

The UpgradeDatabase method must be able to handle the fact that since the list of SQL statements are cumulative then earlier insert or alter statements may encounter constraint errors when they are run again on a subsequent upgrade. That can be worked around by throwing only exceptions that aren’t expected, e.g.

//SQL Lines are split on ';' and put in a commands array 
foreach (string command in commands) {
    cmd.CommandText = command;
    try {
        cmd.ExecuteNonQuery();
    } catch (Exception exc) {
        // Only throw if it's not an expected error due to rerun of the cumulative statements.
        if (!exc.Message.ToUpper().Contains("VIOLATION OF PRIMARY KEY CONSTRAINT") 
          && !exc.Message.ToUpper().Contains("A DUPLICATE VALUE CANNOT BE INSERTED INTO A UNIQUE INDEX") 
          && !exc.Message.ToUpper().Contains("THE FOREIGN KEY CONSTRAINT DOES NOT EXIST"))
            throw;
    }
}

Of course testing must be done on each patch release to make sure the SQL upgrades the DB properly and that expected errors are ignored. The fact that the SQL statements are cumulative eases the burden of handling cases where a user might have skipped several minor releases before installing a release and keeps it pretty simple.

The method is relatively simple and has reliably worked for upgrading client apps that are remotely distributed. The only downside is that it doesn’t handle going back to an earlier version, but if a patch needs to be issued to go back to some schema then that can be done by adding more lines to alter it back to the previous schema.

Write SQL scripts with a huge amount of error handling in them (look for a column to not exist before adding it to a table, look for the table to not exist when creating it, etc.). You can run the scripts as a part of your installation package (results may vary as different installers can make that easier or much harder than necessary), or you can run the scripts when your application starts. If you do the latter, I would recommend moving the SQL scripts to another location so that you don’t attempt to run them more than once.

You can look at all of the available installers out there. I have used InnoSetup with good success running all sorts of executables after placing my files in the appropriate places. I have heard it is possible to do the same with an MSI, but I never got it working. If you decide to use WiX, its Burn tool can create an executable install that gives you both an executable installer and an MSI installer in the same package.