I'm using a setup project in visual studio 2010 for a c# outlook add-in (Office 2010/2013) and an other standalone tool. During the installation I kill all instances of outlook, afterwards I want to restart an instance of outlook.
In my addin project I added an installerclass and added an InstallEventHandler(AfterInstallEventHandler) where I execute
Process.Start("Outlook");
While the same command simply opens Outlook in an other compiled class, in the context of the installer outlook opens in the profile creation assistant.
I also tried to run said working compiled exe as an user defined action after the commit, but same problem occurs.
Any solution or explanation would be appreciated.
In additional to previous answer(I spent a lot of time to understand this):
Text of WiRunSql.vbs for me: (for you it will contains also argument2-update script argument)
(for me PostBuildevent is
)
You can test your script in command promt before:
This need for look errors in script
To look new Type value you can use orca https://support.microsoft.com/en-us/kb/255905
Also look: http://www.codeproject.com/Articles/383481/Editing-an-MSI-Database http://integr8consulting.blogspot.ru/2012/04/microsoft-installer-custom-actions-user.html https://github.com/facebookarchive/ie-toolbar/blob/master/Common/Install/msi/FBIE-MSI/scripts/msipostbuild.vbs
SOLUTION:
The installation runs in the SYSTEM account. Therefor the created process is also run in said account, not as the currently logged in user.
I created an additional project (InstallHelper), which includes the
I added the InstallHelper as CustomAction on Commit in my setup project and changed InstallerClass to False in the properties of the CustomAction. Then I copied WiRunSql.vbs to the project folder and added an PostBuildEvent to the setup project:
3602:
1554:
See: msdn: Custom Action In-Script Execution Options
The Type-change removed the bit for msidbCustomActionTypeNoImpersonate (0x00000800), so the InstallHelper and the created process are run as the logged in user, not as SYSTEM.
Alternatively those changes are possible via opening the msi in orca (has to be repeated after each build, so I prefer the scripted change).