> 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:
And you will see that it is elevated.
![Image]()
> ... 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 conditions detecting install/repair/modify/upgrade/uninstall. This is the reason why I suggested to use AfterInstall as it already has the all information you need. Look at the image above and you will see that SetupEventArgs has property IsInstalled (and others) properly initialized.
> session.IsRepeare() throws exception,
I am not sure what you are referring to. Wix# has
> 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. AfterInstall) helps the situation by preserving all important properties into the session CustomActionData 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
Start with the Setup Events sample. Have a look and play with it a little. Most likely it will satisfy all your needs.
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:
staticvoid project_AfterInstall(SetupEventArgs e) { if (WindowsIdentity.GetCurrent().IsAdmin()) MessageBox.Show(e.ToString(), "AfterExecute (admin)"); else MessageBox.Show(e.ToString(), "AfterExecute"); }
> ... 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 conditions detecting install/repair/modify/upgrade/uninstall. This is the reason why I suggested to use AfterInstall as it already has the all information you need. Look at the image above and you will see that SetupEventArgs has property IsInstalled (and others) properly initialized.
> session.IsRepeare() throws exception,
I am not sure what you are referring to. Wix# has
session.IsRepairing() extension and it doesn't throw as it uses top level try catch. Though if you use AfterInstall 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. AfterInstall) helps the situation by preserving all important properties into the session CustomActionData 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
DefaultUsesProperties, which by default preserves only INSTALLDIR and UILevel. However... I would really encourage you to go with AfterInstall 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.