Search code examples
c#visual-studio-2010setup-projectoutlook-2013

Visual Studio setup project: run CustomActions/process as current user not system account

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.

Solution

  • Solution:

    The installation runs in the SYSTEM account. Therefore 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

    Process.Start("Outlook");

    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 a PostBuildEvent to the setup project:

    @echo off
cscript //nologo "$(ProjectDir)WiRunSql.vbs" "$(BuiltOutputPath)" "UPDATE CustomAction SET Type=1554 WHERE Type=3602"

    3602:

    • 0x800 (msidbCustomActionTypeNoImpersonate)
    • 0x400 (msidbCustomActionTypeInScript)
    • 0x200 (msidbCustomActionTypeCommit)
    • 0x12 (Custom Action Type 18: exe)

    1554:

    • 0x400 (msidbCustomActionTypeInScript)
    • 0x200 (msidbCustomActionTypeCommit)
    • 0x12 (Custom Action Type 18: exe)

    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).