0
votes

I have a setup project created with visual studio installer. I have set some custom actions that will start my custom-made WPF installer after the files are copied for further installation. But I have 2 problems:

  1. Even if I have disabled all windows, there's still a little loading bar from the msi that stays behind my WPF process that I'm starting from a custom action (not that big of a deal, I can live with that). The UI level is 3, and the one from silent install is 2 (which is minimum). I was wondering if there's a way to set the default UI level to 2 (silent no matter what, even when the user double clicks the msi)

  2. This is the biggest problem: The custom action starts my WPF process and waits for exit. If the user cancels the installation (presses the X button in the WPF), the WPF will exit with a certain exitcode that I catch in my custom action. Now, i need a way to perform a rollback from my custom action in this case. The only way i have found is to throw an exception. But the user will then see the ugly dialog window from the msi with the exception, and I definitely don't want that. Can I force the rollback somehow without throwing the exception? Or at least hide the msi's UI?

Note: the custom action I'm using is the Committed event, because i need all the files to be copied (including some assemblies in GAC) for my WPF to work.

I have found a couple of answers on stackoverflow, but none of them were helpful. The closest one was this:

Similar question

Thank you

1

1 Answers

0
votes

You say you have a custom action that starts your WPF program, but you don't say what that code is, whether is NET, VBScript, C++ etc. If that's what's throwing the exception you should show thaqt code.

If it's managed code you throw an InstallException with your message, that's just the way they work because managed code CAs are not native to Windows Installer so there's a shim Dll that deals with stuff.

If the CA that calls your WPF program is C++ or VBScript then there is an API to show your own message, MsiProcess4essage or session.message.

Generally speaking I don't believe you can force a rollback and suppress all messages - a message is always produced. It seems unfriendly to completely rollback the uninstall and uninstall everything without sayting what's going on.