I need set hidden .exe.config that actually resides in application folder. Alternatively, it would good change folder location, example in application data (hidden folder).
You cannot change the location of the app.exe.config file with the default CLR host. It initializes the primary appdomain with the values it finds in the .config file before your code starts running. There's only one place it will look for the file, in the same directory as the startup EXE, using the name of the EXE. Altering the location is technically possible but only if you write a custom CLR host that uses a custom AppDomainManager. Writing a custom CLR host requires COM code written in C++. This otherwise defeats the point of having only a single deployable file.
If you intend to do this to hide sensitive information, like the username+password for a dbase connection string, then keep in mind that security through obscurity is not true security.
If you intend to do this to achieve single-file deployment then don't forget to overlook the standard solution: a single file named setup.exe
Related
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.
I'm trying to use application settings with a C#.NET project I am working on. But I can't seem to get it to return anything other then the default values. Through the project properties I've added a single setting, DBConnectionString, and set its value to a connection string I want to use. Its scope is set to "application".
Doing this created a number of files including Settings.settings, Settings.Designer.CS, and app.config. The Settings class then has custom, type safe, properties that can be used to set and retrieve each setting. The app.config file is a XML file that stores the actual settings values.
When I build my project it looks like the app.config file is copied to the target directory as DataAccessLayer.dll.config. My program runs fine and is able to use the default connection string.
Next I tried to edit the DataAccessLayer.dll.config file to change the connection string. I ran my program again, but it continued to use the default value.
This project is a class library that use to a Web project and sometimes the connection string can changes.
Builds will output config files named after the dll however those aren't actually what's read on app start up. You could put the setting in the web apps config (example here Equivalent to 'app.config' for a library (DLL)), those are the settings you'll actually be running with in this case.
If you want your library to be portable you'll have to either; 1) make your own config class/file 2) Read your dll's app config manually (example in the answer I linked to above) or 3) Put your setting in the importing projects app.config
In this case I would just put your connection string data in the web apps config. If DataAccessLayer.dll is only for internal use, this is in my experience the most common pattern, and doesn't really have many cons. Ultimately I would have these values set during my build or by a deploy utility like Salt or Chef. If you're manually editing the web apps config on or after deploy then you're doing it wrong.
I'm creating an application and I make use of Properties.Settings to store the settings.
However, let's say my application is on the desktop of the user and is called Program.exe, now, when the user copies this executable and places it somewhere else or even renames it, all settings are gone.
Why is C# doing this? Is there any way this can be turned off while pertaining the user scope? I don't wish to use the application scope since multiple users can be sharing the same computer.
The settings are likely stored in {appname}.exe.config which apparently is not being copied/renamed with the executable. Either copy the executable with the file, hard-code them in the application, or find another mechanism to get/set app settings (like the registry).
The application will look for these settings in a file titled {appname}.exe.config. If the executable is renamed (without renaming the .config file) or copied to another location without copying the .config file along with it, the application won't know where to look for their settings so they will be blank (unless you set a default value in the app).
You can "hard-code" default settings by putting a value in the Settings.settings "file" in Visual studio (which effectively adds the default value as an attribute to the setting).
Another option would be to hard-code the values directly in the source code. I'm NOT recommending this approach as it hinders the ability to change that value, but if you want to be able to deploy the app by just copying the EXE (and nothing else) then it is an option.
See http://msdn.microsoft.com/en-us/library/aa730869(v=vs.80).aspx for details.
The settings (and their location) when using Properties.Settings is determined by the Scope setting of the particular setting.
Settings that are Application scoped are in the app.config file (renamed at compile time to .exe.config - these settings are read only at run time), and settings that are User scoped are saved in a user.config that is tied to the user's profile on the machine (these settings are read/write at run time). By properly scoping your settings you should be able to avoid this type of problem.
Settings are stored in the user profile (under C:\Users[UserName]\AppData\Local), these settings are under folders that have the application name and also have an identifier of the location of the exe file they refer to, for example: MyApp.exe_Url_hpvvra0rj4y03ebpz3cfmzsrcpczat11, refers to the executable under Program Files, if i move or copy the exe and run it, it will create another folder with another URL (MyApp.exe_Url_vqzsq0spwewydv3wrnebtqji24nwuboe, for example), i haven't find a way to avoid this but a good workaround is to copy the settings from another config file, just note that this method is not foolproof as you have to choose the right file to copy the setting to and if you expect your exe to be copied or moved constantly this will be a hard task.
Another workaround is to simply create your custom settings class and put the file anywhere your application can find it and don't realy on the built in settings on .NET.
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).
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.