Use admin privilege on WIX custom action

1
votes

Glytzhkof: This question relates to a common problem for new MSI users, the belief that one needs a custom action for something MSI supports natively by a feature they are unaware of.

In this case the IniFile table in MSI that allows merging, rollback and updating of shared Ini files on the system. All updates to Ini files should be performed via this table since you get a lot of features for free and you will be in line with all MSI guidelines.

Always avoid custom actions if there is a way to achive the same effect by native features.

I have a c# customaction on my WIX msi.

When msi start require admin account and all works fine excepted for my customaction, it can't write inside programdata folder.

I have set impersonate="no" according to wix reference:

This attribute specifies whether the Windows Installer, which executes as LocalSystem, should impersonate the user context of the installing user when executing this custom action. Typically the value should be 'yes', except when the custom action needs elevated privileges to apply changes to the machine.

But does not works.

This is my custom action configuration:

<CustomAction 
Id="MyCustomActionCA" 
BinaryKey="mycustomactionDLL" 
DllEntry="MyCustomAction" 
Execute="immediate" Return="check" Impersonate="no" />

<InstallUISequence>
  <Custom Action="MyCustomActionCA" After="CustomDialog1">NOT Installed</Custom>
</InstallUISequence>

MyCustomAction is launched after CustomDialog1 is closed, and this is OK, my code run fine but in MyCustomAction i have a line of code like this:

File.WriteAllText(mypath, mycontent);

mypath refers to ProgramData folder and throw an exception becouse user can't write inside it.

3
c#wixwindows-installercustom-actionini
You need to give more information. What specific error(s) are you getting? Have you validated your custom action code to make sure the problem is not there as opposed to your Wix configuration? Post code and/or the appropriate sections of your .wxs file so we can actually help you. – Daniel Simpkins
The error is that user can't write on programdata folder at row File.WriteAllText(myini, myiniContent). I'm debugging my customaction using System.Diagnostics.Debugger.Launch() on top of my method. – workat
So you've verified that your CA code is definitely being called? Once again, please edit your post to include the appropriate code/config so we can be of more help to you. – Daniel Simpkins
Yes, it is. Ok i add more infos, thank you. – workat
Maybe the problem is that mycustomaction must be "deferred"? – workat

3 Answers

0
votes

Check this thread for information on how to use MSI's built-in support for writing to INI files: Wix modify an existing ini file

Some further reference: http://wixtoolset.org/documentation/manual/v3/xsd/wix/inifile.html

2
votes

There seems to be two problems here as far as I can tell:

  1. The first is that the CA needs to be deferred if it's impersonate="no", and it's not clear that you've done that.

  2. The second problem is that ProgramData is a user profile notion. For example it's in C:\Users\ on my system. If you run with impersonate="no" you're running with the system account, so it's going to try to write to some weird (non existent) C:\Users\System folder.

You might have a design issue here in that you say you need elevated user privileges to write to that folder, but you can't elevate unless you are deferred with system account privilege. You may need to describe the exact problem you're trying to solve to see if there is another way.

0
votes

Best option: redesign your application to write this ini file as a per-user file (any user can write to his own user profile) on application launch from internal defaults in the exe itself. Solves the deployment problem too.

As to what is happening in your deployment context: Windows installer runs only part of the installation as LocalSystem - what is referred to as the installation transaction. The rest of the setup is run as the user who launches the MSI - and this includes the entire user interface sequence which is where you have added your custom action.

Try setting the action deferred, schedule it prior to InstallFinalize and set impersonation to no.

With regards to per-user data management, see this post on a slightly different topic for a way to handle per-user data that needs management between deployed versions of the application: http://forum.installsite.net/index.php?showtopic=21552