Is there any special documentation on exactly what adxregistrator.exe is doing?

Add-in Express™ Support Service
That's what is more important than anything else

Is there any special documentation on exactly what adxregistrator.exe is doing?
 
SilverStr




Posts: 28
 Joined: 2013-03-31
Hey guys,

In my quest for a single MSI via WiX I have found out that the elevation issue in which the BHO is not registering correctly unless I call msiexec from an elevated cmd window is coming down to the CustomAction that is calling adxregistrator.exe. The gurus over at WiX believe that if I allow WiX to do the registry creation and what not that there is a good chance it will work.

In an effort to try to make this work, is there any references or guidance I can read that explains EXACTLY what it is that the adxregistrator.exe binary is doing? Any assistance you provide will be returned on this thread with a final set of actions that work (if I can get it to work)in the .wxs so others using Add-In Express who want to go the WiX route can do so in confidence.

Thanks in advance for any knowledge sharing you can provide!
Posted 17 Jul, 2013 10:34:32 Top
Andrei Smolin


Add-in Express team


Posts: 18821
 Joined: 2006-05-11
Hello,

SilverStr writes:
is there any references or guidance I can read that explains EXACTLY what it is that the adxregistrator.exe binary is doing?


Actually, I've just answered this question when repplying to your other post, please see http://www.add-in-express.com/forum/read.php?FID=10&TID=11752. I understand that this is not a technical desription. Still, I believe it suffice at this stage.

I would like to understand why you think adxregistrator behaves incorrectly.


Andrei Smolin
Add-in Express Team Leader
Posted 18 Jul, 2013 10:48:19 Top
SilverStr




Posts: 28
 Joined: 2013-03-31
Hey Andrei,

I sure can provide feedback. I am talking with the guys who were responsible for WiX internally at Microsoft, and who have since began to work on it as open source. Here is an exact sentence from them in one of our communications when I was asking about how the CustomAction you built as part of your setup wizard handles the elevation within the MSI:

@Impersonate="yes" means that the custom action will run with the same user token as the original MSI was launched with. That means that if you don't preelevate you get the non-elevated token (and thus, operations requiring elevation will fail). Your third-party framework is performing a form of SelfReg, and all of the evils associated with it still apply. Push back to them to supply the actual registration. SelfReg is only ever appropriate for developer boxes that require the component to be registered in order to program/debug against it (and even then only if your developer box is in a VM and can be easily rolled back).


So if I can find out exactly how the BHO is being registered in your adxregistrator I should be able to make the equivalent WiX commands, and properly handle the elevation, and finally put this mess behind me. When done, the single installer will handle everything I need.

BTW, WiX can build a single EXE using Burn. So if I decide I want to do it as an exe, it will definitely work. There is no need to use your setup.exe at all. So once we can properly get the TECHNICAL information on what is required to register the BHO, I should be good to go.

Regards,
Dana
Posted 18 Jul, 2013 14:03:52 Top
Andrei Smolin


Add-in Express team


Posts: 18821
 Joined: 2006-05-11
Hello Dana,

The citation consists of two parts: 1) on impersonation and elevation and 2) on SelfReg. And I believe they don't relate to each other.

#1. When talking about elevation (and impersonation), you need to understand that Add-in Express recommends using only two combinations of settings, namely a) for a per-user add-in and b) for a per-machine add-in. This is described in the section "Determining Privileges" in the manual, see the PDF file in the folder {Add-in Express}\Docs on your development PC.

Now note that per-user add-ins don't require elevated privileges: they create files in the user's profile (at least, this is so by default) and write to HKCU.

That is, only per-machine add-ins require elevation: they create keys in HKLM and they write to Program files (well, by default). For the installer to run elevated, this tag is added to the Package node: InstallPrivileges="elevated". (We are talking about WiX).

If you return back to the manual, you'll find that a per-machine add-in is registered by passing /privileges=admin to adxregistrator.exe. You can create a new add-in and experiment with the RegisterForAllUsers property (it specifies if the add-in is per-user or per-machine) and setup projects that Add-in Express generates.

That is, I beleive there should be NO issues related to elevation and adxregistrator. If you think otherwise, please provide a description of the issue that you are experiencing.

#2. En principle, I agree that SelfReg is sort of a black box and this creates a degree of uncertainty: Does this black box works or not? On the other hand, a specialized and well-behaving black box performing a predefined set of tasks and creating a log, and the source code of which is available (for Premium customers only!) isn't that black, huh?

Not using adxregistrator.exe
- creates problems for developers of different specializations and beginners,
- increases the number of problems, note that the problems are mostly typical
- complicates the development of an add-in
- makes the add-in costlier.

Costlier? Yes, you need to know or find out how to create and delete registry keys, what keys must be created in what cases, in what cases to run the host application to perform cleanup. Then you need to implement all of these and debug them.

Well, I think this is a contraposition: the cleannes of theoretical constructions vs. the logics of practice.

As always, if you think otherwise, please describe your scenario and we will try to help.


Andrei Smolin
Add-in Express Team Leader
Posted 19 Jul, 2013 06:47:01 Top
Andrei Smolin


Add-in Express team


Posts: 18821
 Joined: 2006-05-11
Oh, I'm sorry. I've just noticed that this is the "for IE" forum. And I refered to the "for Office" manual in the post above.

Anyway, the "for IE" installation principles don't differ much from "for Office". IE Bar projects are per-user, while BHO and IE toolbar projects a per-machine. Accordingly, Add-in Express sets the InstallPrivileges tag to "limited" or "elevated" and pass /privileges=user or /privileges=admin.


Andrei Smolin
Add-in Express Team Leader
Posted 19 Jul, 2013 07:24:38 Top
SilverStr




Posts: 28
 Joined: 2013-03-31
Working with Microsoft I got this solved. The problem was you have conflicting elevations in your generated WiX project. To fix the problem, here is what I had to do:


  • Remove the InstallPrivileges="elevated" from the "Product" section
  • Change the CustomAction to say Impersonate="no"


The problem is when you say perMachine and then say elevate for install privileges, those apparently conflict. And was depreicated some time ago. And when you have Impersonate to "yes" as your wizard sets it to call your registrator exe, it uses the security token of the caller. So even though the MSI elevates, the caller is the standard user, so the CustomAction tries to run using the user's token, which doesn't elevate and therefore fails.

The reason it "always" works when running your setup.exe is because you elevate and THEN call the MSI, which means the caller would be elevated.

I now have a single MSI which when I double click installs the BHO to all users on the system. No need for a second setup.exe file and properly registers it in Windows 7 and Windows 8. Only had to change those two pieces in the Product.wxs.

I'd recommend you change that in your wizard. Would save a world of grief for your users.
Posted 19 Jul, 2013 17:44:45 Top
Sergey Grischenko


Add-in Express team


Posts: 7233
 Joined: 2004-07-05
Hello,

Thank you for the suggestion. But using your recommendation causes custom actions to run under the System account rather than under the account of the user who runs the installation. This may cause issues in setups that write entries to the current user's registry key. Moreover, setup.exe is used to install the prerequisites. So, we will continue using a setup.exe. Of course, you can change your setup program in the way that meets your requirements better.
Posted 22 Jul, 2013 10:54:57 Top