CODEWITHSUNDEEP
c#wixwindows-installercustom-actionini
workat
workat

Reputation: 63

Use admin privilege on WIX custom action

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.

Upvotes: 1

Views: 6385

Answers (3)

Stein &#197;smul
Stein &#197;smul

Reputation: 42126

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

Upvotes: 0

Stein &#197;smul
Stein &#197;smul

Reputation: 42126

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

Upvotes: 0

PhilDW
PhilDW

Reputation: 20780

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.

Upvotes: 2

Related Questions