We Keep Coding

How to allow for editable .Net generated config files with MSIX?

I am trying to help port a .Net service to a more modern .Net version (possibly Core) and use the MSIX installer. The application has several configuration files generated by the compiler (in source they are app.config but compiled they become *.exe.xml), they are installed into Program File right next to the binaries and a GUI helper app as well and the application itself can modify them to change service behavior (port, ip, tls cert, etc).
Writes under C:\Program Files\WindowsApps\package_name are not allowed.Writes under C:\Program Files\WindowsApps\package_name are not allowed.
The problem I am facing is that the MSIX installer makes it so that files in it's sandboxed version of Program Files cannot be written to (see above). That means that this application cannot be configured, so I am trying to figure out not only how to make the app configurable again, but also how windows wants to handle app configuration.
Right now it seems like there is two general approaches to do this:
write the configuration data to the service account's AppData/local folder
try to mimic a /etc/Myservice behavior in another folder. (meaning a local system-wide directory that houses configuration data for the service)
If you suggest #1 please answer the following additional questions:
How would I move Application configuration files to a user configuration file directory
how can an admin with a normal account modify the config file in the Service Account's AppData folder with the mentioned GUI helper application? (do they need to enable desktop access to the service account, login and run the GUI)?
If you suggest #2:
Where would you suggest this directory exist (specifically where will MSIX allow it)?
How do I tell the .Net application that the files are not right next to it? Can I just use AppData.CurrentDomain.SetData?

Well, a service running on the system account is the same for all users, so I would say that CommonApplicationData is a better folder for storing its settings, instead of appdata. This folder is easily accessible to both your service and to any admin that needs to deploy a custom config file.
In AppData you should store only actual user files (like files or settings generated by the actions taken inside your app by a specific user - thus different files for different users).
Now, the second part is where you need to configure you code to load the config file from a custom path instead of looking for it next to the EXE. I am no .NET expert but after a quick search I found this:
Relocating app.config file to a custom path
The modern approach to deploying app customizations
What is not clear to me is how your customers use the GUI helper tool to customize the config file. Is this just a tool that is used by someone from the IT department to generate the config file, and then they would copy that file and deploy it to the end-user machines using an MSI/MST file (or through some other custom deployment method)?
If your application is only deployed by IT folks, then you can try another simpler (and much elegant) solution for providing it with a custom config file, which actually doesn't require any code changes.
You can still leave the config file next to the EXE, in ProgramFiles and instruct the IT teams that deploy the app to use an MSIX Modification Package to deploy the custom config file generated by your GUI helper. (check the link included above for an example - with a video version at the end of the article).
Note: IT teams can use multiple free or paid tools to generate MSIX Modifications Packages.
Of course, your GUI helper tool still needs to generate that customized config file in a folder where it is allowed, as it can no longer write under ProgramFiles. So actually, you do need to modify a little bit your code in this scenario too.

C# App.config vs Settings File

This may sound like a trivial question, however I have looked over the web briefly and what I found was that app.config is basically an older mechanism for storing Application key/pairs of data for the application.
What I want to know is there any reason we (as .NET developers) would opt to use app.config over a Settings file ?
-Can someone please provide some pros and cons on both so we can use them properly.
thanks again

App.config for desktop applications and Web.config for web applications are part of .NET configuration system. Primarily they are used to control .NET framework settings in respect to our application. These are such configuration settings as substitutions of versions of assemblies (section <assemblyBinding>), substitution of .NET framework version (<startup>) etc. (see msdn for the full app.config schema.) One section is dedicated for custom settings of application developers (<appSettings>). There is also a possibility to create custom sections. So, when we need to store settings we can either piggy-back on the app.config or create our own separate configuration files.
Here are pros and contras of using app.config:
Pro: There is already a standard API in .NET to read settings from appSettings section. If you only need just a couple of config settings, it is much easier to use this ready API than to develop and test your own class to read your config files. Also, app.config file is already included in VS project for you.
Pro: There is a standard hierarchy of machine.config/app.config. If you plan such settings that can be set machine-wide and overridden or left as-is for individual applications, you should use app.config.
Pro/Con: App.config is cached in run-time. If you anticipate updates of it while your application is running, you need to specifically request refresh of certain section of config file. For web.config the web app is automatically restarted when something is changed in the file. This is quite convenient.
Con: app.config is stored in the same directory as your .exe file. Normally it will be in a subfolder of C:\Program Files. This directory is extra protected in Windows 7 from writing. You need to be member of Administrators group to write there and if your UAC (User Access Control) level in Control Panel is not set to 0 (which normally is not), you will be asked by the OS to confirm writing to c:\Program Files. So, users without Administrator rights will not be able to change configuration in app.config. Same goes for changing your settings programmatically: your application will get exception when attempts to write app.config if it runs not under an admin user on Windows 7. Your own config files usually go to C:\ProgramData\ or c:\Users subfolder (on Windows 7). These locations are friendlier to writing by users or programs.
Con: If user edited your app.config file and accidentally corrupted it, the whole application will not start with some obscure error message. If your separate config file is corrupted, you will be able to provide more detailed error message.
In conclusion: app.config gives you easier (faster development) approach, mostly suitable for read-only settings. Custom settings file gives you more freedom (where to store file, validation/error handling, more flexibility with its schema) but requires more work during development.

You have it backwards, the settings file (or ini file as they were originally called) was the mechanism used to hold application settings (key/value pairs) prior to Windows 95. With the release of Windows 95 it was recommended that application settings be moved into the Windows Registry (which proved problematic since if you screwed up your registry your Windows may no longer be able to start).
The .config file came into play with .Net. The XML format allows more dynamic and complex settings configurations than simple key/value pairs.
The modern user/settings file is an XML extension of the .config file (settings that can override certain settings in the .config under specific conditions).

Access to SQL CE database in Program Files directory

I've read a bit that putting a.NET 2.0 SQL CE database in the program files directory where the application is installed is a bad idea. I'm running into the following error:
Access to the database file is not allowed. [ File name = C:\Program Files (x86)\MyCompanyName\MyApplicationName\MyCEDatabaseName.sdf ]
So I've heard, put it in Common Application files.... I'm not sure where that is, and I've read that the installer may drop the file there with the same permissions. I've also read that people have moved their file there and had issues.
Is it possible to change the ACLs of the file in the program files directory when the installer drops it there? I already have hooks into the application from the MSI to collect and set configuration options. I haven't found a good example of how to change the permissions on ONE file.
Then I've read to store it in the user's application data, but if you're installing the application 'for everyone' where will the file go?
Thanks for your time.... confused.

I assume you are using a MSI package. In this case you can use CommonAppDataFolder which is resolved to "C:\ProgramData".
However, this is also a per-machine location, so it requires the same privileges as Program Files. I think you heard about Application Data folder (AppDataFolder) which is a per-user location (something like "C:\Users\\AppData\Roaming"). It doesn't have permission problems.
If you want to use a per-machine location a solution is to use the LockPermissions table:
http://msdn.microsoft.com/en-us/library/aa369774(VS.85).aspx
This is a bit complicated because of all the permission flags. So if your setup authoring tool doesn't offer support for setting permissions, I suggest a simpler approach: use xcacls.exe as a custom action:
http://support.microsoft.com/kb/318754
This way all users can gain access to your database file.

file write permission issue under "Program Files" folder

I am using inno setup to make a installation package for my application, and my application is written by C# + .Net 2.0 + VSTS 2008. Inno setup => http://www.jrsoftware.org/isinfo.php and I install my application under Program Files/Foo folder (Foo is my application name). My application is targeting to Windows Vista.
The issue I found is my program cannot write to the folder Program Files/Foo. And I need the permission of write to this folder in order to save some configuration files. The strange thing I notice is the folder Program Files/Foo is marked as readonly and I have checked all folders under Program Files are marked with read only, such as Office.
My questions are,
Why all folders are marked as read only under Program Files? It means we should not write to individual application folders under Program Files? If not, where should we write information to disk like user last selected configuration information of an individual application?
If we could write to individual application folders under Program Files, what is the solution? I do not want my application to Run As administrator to solve this issue, and if there are solution to write to this folder, I want to require minimal permission if possible.

You should write user specific config data to the Application Data folder for the current user, using the special folders enum and the Enivronment.GetFolderPath.

Best Practice is to not store config data in the Program Files folder. Instead, store your application's data in %AppData%\YourApplicationName. Depending on whether you want to store your config data per-user or in a shared common folder, use one of the following enums to get the folder path:
string userAppData = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
string commonAppData = Envrionment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData);
By default, Vista users do not run programs as Administrators and hence those programs have only read access to the folders under "Program Files". Users can change this behavior by disabling UAC and you could ask your users to do that, but in an office setting users might not have that option. That's why you use AppData instead -- applications can always read and write data to the AppData folder.
Information on UAC can be found at Microsoft's site. Although this page is fairly long, it's a starting point for understanding UAC:
http://msdn.microsoft.com/en-us/library/bb530410.aspx

A common solution would be to install configuration files to the Application Data folder i.e. like follows:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)

where property.setting value stored in c# windows application

I thought it should be a config file, but cannot find it.
thanks

The whole config file location can be a bit slippery. Depending on whether or not its a "user" setting or an "application" setting, it will go into a different file. Some settings can even come from your "machine" config (Like in the case of ASP.NET). Instead of guessing where everything is, I find it much more useful to ask .NET where it is looking for these files. Roughly:
//Machine Configuration Path
string path1 = ConfigurationManager.OpenMachineConfiguration().FilePath;
//Application Configuration Path
string path2 = ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.None).FilePath;
//User Configuration Path
string path3 = ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath;
App.Config
This is what gets added to your project. The build process will name it [myproject].exe.config. This holds the (mostly) read only application settings and the application-level defaults for user-specific settings. Application level settings are difficult to programmatically change their values. Application level setting properties will only have "get" defined. The intention is: if your setting is for all users of the application, then a manual edit (or the installer) should set them. If it changes per user, then make it a per-user setting.
Binary Default Settings
Your application will run without its [myproject].exe.config file. To do this, the binary has its own version of the file "stored". This is useful in some ways, but can be confusing. If you have a .config file in the wrong place or with the wrong name, .NET reverts to the "binary defaults". It can cause the appearance of not being able to affect the settings by changing the config file. Use the method above to know where the .config REALLY goes, or face the wrath of the binary default settings.
User.Config
This is generated the first time you "save" your Default.Settings object with a "per-user" setting. This file is saved in the user's profile path in a location based on your project's name, version, operating system, and some other dark .NET magics. The properties for these settings are readable/writeable. They are designed to be easily set and then saved with a single call.
Pulling it Together
So where do my settings go? The answer is that potentially many files are joined together to get the "Active set" of settings. App.config and user.config settings are the basic blocks, but there are machine.config settings, and then there are dependency assembly settings that can further complicate things...but thats another topic entirely.
The real truth of config files is spread across a lot of ugly cases and details. However, with a little knowledge about how they are joined together, it is a fairly useful system. Especially if you realize you can databind to these settings ;)

If you're talking about .Net settings, then they will normally be in a .config (xml) file in the same directory as the application. When you save them, however, a local copy gets saved in to a user writable folder (typically C:\Users\username\AppData\Local under Vista). Under XP, look in the Documents and Settings folder.
The .Net application uses this file in preference to the 'default' one in the application directory.
Hope this helps.

On Windows XP, it's stored in a file called user.config in a subfolder of:
C:\Documents and Settings\username\Local Settings\Application Data
http://dotnetproject.blogspot.com/2006/08/where-is-userconfig-file-located-in.html

Are you referring to the .settings file in your application? When you add values to that file, an app.config file gets created for you. You should be seeing it in your solution explorer.