JimBoone
JimBoone

Reputation: 554

How do I write to a non-standard config file?

I have a file called middle.config that is deployed in the same directory as an exe, but I need to update values in this file. That means that I have to go to C:\Program Files (x86)\ directory to access the file. Although it is named as a .config file it does not follow the usual schema of a .config file. It looks like this:

<configuationSettings>     
  <middleSettings      
   groupName="XYZ"     
   forkName="SomeDbName"     
   dbServerName="123.123.123.123"     
   cnnTimeoutSeconds="30"     
   cmdDefaultTimeoutSeconds="30"     
   cmdMediumTimeoutSeconds="60"     
   cmdLongTimeoutSeconds="480"     
   />     
 <userKeys>     
   <Assemblies value="C:\assemblies\" />     
 </userKeys>     
 <friendlyDbName value="NiceData"/>     
</configuationSettings>     

I'm able to read and manipulate the content with Xml, but when I try to save the file back, a "No Permissions" error is thrown. I cannot relocate the file. I'm stuck with this legacy schema so I'm not able to treat it like a normal .config file using ConfigurationManager.OpenExeConfiguration. I cannot define sections or groups on this schema (I've not been able to anyway). All my users are Administrators on their local machines.

How do I overwrite or delete and replace this file while it is in a protected directory(my assumption about the permissions error)? Failing that, is there a way to access this schema somehow with ConfigurationManager.OpenExeConfiguration.

{edit starts here}

There are three applications in this scenario, A, B, and mine C. Application A does not know about any other applications. It can connect to many, many databases, and it drops a single file 'middle.config' that contains pointer info to the last database location that was used by the last Application A session. Application B, let's call it an import/export application, only operates on the last Application A database location. Application B reads the 'middle.config' file for database pointer info and then executes console commands against that database. It performs bulk dumps or bulk imports for selected portions of the database.

This was the situation when I come along to build application C that uses the import/export application B to fetch, blocks of data and return them to the database. So, in order for application C to use Application B against any database, application C must modify the 'middle.config' file so that application B will find the correct database. Application C is new and the other two are legacy. I either find a way to make this work, or I force the user to start Application A and point to the database of interest, then close Application A. This is VERY unhandy.

{edit ends here}

Upvotes: 0

Views: 415

Answers (5)

Trey Gramann
Trey Gramann

Reputation: 2004

From a different angle, look at this: Writing custom sections into app.config

I found the linked article to be very useful. Not sure it is going to answer all your questions though.

Upvotes: 0

Makubex
Makubex

Reputation: 1114

Move the logic to a separate process and launch it with admin privileges from your current application.

Upvotes: 0

anton.burger
anton.burger

Reputation: 5706

Your assumption about protected directories is correct. Program Files has an Access Control List which prevents modification by processes running as standard users and, on Vista upwards, even by administrator processes which are not running elevated. Accessing the file using the standard configuration classes would not get around this.

If you absolutely can't move the file (Eric J. is right when says that writing to Program Files after installation is a bad idea), then you could embed a manifest in your config file-editing program which will try to force elevation with a UAC prompt at launch. Of course, the best solution would involve a) using standard config schema and b) keeping user data in user-writeable locations, but sometimes that isn't possible for legacy reasons.

I'm not aware of any way to persuade ConfigurationManager to read a non-standard schema, unfortunately.

Upvotes: 0

Quintium
Quintium

Reputation: 497

Suggested that your app is creating its own location under the AppData location folder for the current user instead of writing to files under location where the the app is installed (especially if under Program Files which is very strict.) Not suggested to force the user to run as Administrator for your application either.

Upvotes: 0

Eric J.
Eric J.

Reputation: 150108

It is not advisable to write data files to the program files directory, as this requires elevated permissions. Giving a program elevated permissions just to update a config file clashes with the Principal of Least Privilege, which states that

a particular abstraction layer of a computing environment, every module (such as a process, a user or a program depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose

It's not a "legitimate purpose" to give the process elevated permissions (that can allow it to do many harmful things) just to update a config file. MS recommended practice is to write that type of data elsewhere.

Instead, consider storing the config file in a subfolder of the ApplicationData folder.

Upvotes: 3

Related Questions