|
EnterpriseDev
Guest
|
I created the default WIX installer using your template. When I double click on the MSI and continue with the installation (from an admin Windows account), I get through the installation process but the add-in fails to register, see below. However, if I open "cmd" as admin and then run through the same installer everything works fine and the add-in is properly registered.
How do I modify the WIX installer to run as admin (elivated) for my per-machine MSI file?
Thanks.
Installation directory: C:\Windows\Installer\
Registrator version: 8.2.4371.0
Operating System: Microsoft Windows 10 Professional (build 10586), 64-bit
Process Owner: Administrator
Command Line: "C:\Windows\Installer\MSIEA1C.tmp" /install="C:\Program Files (x86)\Default Company\MyAddin1\MyAddin1.dll" /privileges=admin
Run 'As Administrator': No
Process Elevated: No
Integrity Level: Medium
UAC (User Account Control): On
|
|
|
EnterpriseDev
Guest
|
I changed the WIX attribute to Impersonate="no" on all custom actions. Now the default WIX installer is working.
Why are you not including impersonate="no" per default in the installer, or does everyone has to change this who has a per-machine installer with the default installer directory settings? |
|
|
Andrei Smolin
Add-in Express team
Posts: 18817
Joined: 2006-05-11
|
Hello,
EnterpriseDev writes:
Why are you not including impersonate="no" per default in the installer
This is sort of philosophical question ))
Personally, I believe that people misunderstand setup.exe: they treat it as just a different and (seemingly unneeded and useless) way to start the installer. But as you know you *must* start setup.exe to install prerequisites. Since installing prerequisites requires administrative permissions, we've chosen to prepare the installer to be run this way.
In a lesser degree - still important - we tried to minimize the flow of problems on the support desk. That is, we always describe starting a per-machine installer as starting setup.exe (not the .MSI). In this case the installer is always run elevated.
In your case, the impersonate attribute set to "no" works in this way (I assume UAC is on): you double-click the .MSI file and the installer is run with the Standard privileges; when the installer starts copying the files to Program Files (or a similar folder) UAC is triggered and this elevates permissions; from this moment, the installer and custom actions are run with elevated permissions. If your add-in is never meant to install prerequisites, this approach is okay. Still, this results in your users getting used to this way of starting the installer. I prefer the users to get used to start setup.exe (if present).
In short, by choosing "yes" we insist on starting setup.exe. By choosing "no", you allow the user to start the .MSI.
Andrei Smolin
Add-in Express Team Leader |
|
|
EnterpriseDev
Guest
|
Hi Andrei,
Thank you for your answer. In my specific case, I have no prerequisites so I prefer to give a single MSI file for deployment. It can be confusing for user if they should choose an EXE or MSI file. I will then continue with the approach to use Impersonate="no" in my installer.
By the way, I really like that ADX manages to use the same MSI file to register the DLL independent if it is registering it for Office 64-bit or Office 32-bit. |
|
|
Andrei Smolin
Add-in Express team
Posts: 18817
Joined: 2006-05-11
|
Thank you for the kind words.
Andrei Smolin
Add-in Express Team Leader |
|
Forums
Topics
Search
Help
Login
Register