> But the project_afterInstall and other built-in handlers during uninstallation has less permissions (somehow) when during installation.
Actually it is vice versa. AfterInstall
is deliberately based on the deferred custom action so you have elevated execution context.
Modify the Setup Events
sample as below:
static void project_AfterInstall(SetupEventArgs e)
MessageBox.Show(e.ToString(), "AfterExecute (admin)");
And you will see that it is elevated.
> ... press Repair button on setup.msi...the same custom action (UnInstallCertificatesAndStopTaskAction) is called again (like in unstallation process)....
Correct. All custom actions are executed every time msi is executed unless they are bound to the
detecting install/repair/modify/upgrade/uninstall. This is the reason why I suggested to use
as it already has the all information you need. Look at the image above and you will see that
has property IsInstalled (and others) properly initialized.
> session.IsRepeare() throws exception,
I am not sure what you are referring to. Wix# has
extension and it doesn't throw as it uses top level try catch. Though if you use
then you just need to evaluate the SetupEventArgs
(CLR not session) properties.
> Really I have only 2 properties in sesssion: INTSALLDIR = "C:\Program Files..." and UI = 3.
Correct. This is that known MSI limitation: all deferred (elevated) custom actions are executed outside of the session and no session properties are available. Wix# (e.g.
) helps the situation by preserving all important properties into the session
and then exposing them as CLR properties to the deferred actions. You can also do it by yourself for any deferred action by adjusting the project
, which by default preserves only INSTALLDIR and UILevel. However... I would really encourage you to go with
as it does exactly what you need.
Start with the Setup Events
sample. Have a look and play with it a little. Most likely it will satisfy all your needs.