1 0 ConsoleEcho.exe.config:

0 0 0 0 ---------- 20191224 AppSettingsSection 存取方法: using System.Configuration; static void Main(string[] args) { string sBaseDir = AppDomain.CurrentDomain.BaseDirectory; string sExe = AppDomain.CurrentDomain.FriendlyName; string sFileDebug = Path.Combine(sBaseDir, "debug.txt"); Debug.Listeners.Clear(); TextWriterTraceListener listener1 = new TextWriterTraceListener(File.CreateText(sFileDebug)); Debug.Listeners.Add(listener1); Debug.AutoFlush = true; Debug.Print($"sFile={sFileDebug}"); Console.InputEncoding = Encoding.UTF8; Console.OutputEncoding = Encoding.UTF8; Console.CursorVisible = true; // 20191224, Honda. // Console.WindowLeft, WindowTop not working! int iWidth = 0; int iHeight = 0; string sLine; // OpenExeConfiguration // 或 OpenMappedExeConfiguration // 或 OpenMappedMachineConfiguration // 或 OpenMachineConfiguration Configuration config1 = ConfigurationManager.OpenExeConfiguration(null); AppSettingsSection setting1 = config1.AppSettings; int.TryParse(setting1.Settings["Width"].Value, out iWidth); // 20200101, 不好用! 讀不到時, 這裡會 null exception 中斷出去! int.TryParse(setting1.Settings["Height"].Value, out iHeight); if (iWidth > 0) if (Console.WindowLeft + iWidth < Console.BufferWidth) if (iWidth <= Console.LargestWindowWidth) Console.WindowWidth = iWidth; if (iHeight > 0) if (Console.WindowTop + iHeight < Console.BufferHeight) if (iHeight <= Console.LargestWindowHeight) Console.WindowHeight = iHeight; while (true) { sLine = Console.ReadLine(); if (sLine == ".end") break; else Console.WriteLine(sLine); } // 20191224, Honda. // Console.WindowLeft, WindowTop not working! //setting1.Settings["Left"].Value = Console.WindowLeft.ToString(); //setting1.Settings["Top"].Value = Console.WindowTop.ToString(); setting1.Settings["Width"].Value = Console.WindowWidth.ToString(); setting1.Settings["Height"].Value = Console.WindowHeight.ToString(); config1.Save(ConfigurationSaveMode.Modified); } 範例: App.config ---------- 20191030 To understand the pros and cons of settings in the app.config, I suggest that you look into the technical details of both. I have included links where you can find source code for handling, describing more technical details below. Let me briefly summarize what I recognized when I worked with them (note: the same is applicable to the web.config file of a web site / web application): applicationSettings (click above to view source code and technical details) Pros They allow to store typed data, including object types (via serializeAs property) They have a user and application scope, allowing to store default values They are supported in Visual Studio's configuration section Long strings and/or data with special characters are very well supported (for example, embedded JSON strings containing double quotes) Cons User settings are stored in a different place in the user profile (with a cryptic path), can be difficult to clean up Application scope settings are read-only during runtime of the application (only user scope settings can be changed during runtime) Read / Write methods code built by Visual Studio's settings designer, not directly provided by 3rd party tools (see link above for a workaround solution) AppSettings (click above to view source code and technical details) Pros Are "light-weight", i.e. easy to handle Read and write access during runtime of the application They can be edited easily by Administrators in the Internet Information Services (IIS) Manager (Features View -> Application Settings, note that the name of the icon is misleading since it can only handle AppSettings and not ApplicationSettings) Cons Support only string data; string length and special characters are limited They don't have a user scope They don't support default values Are not directly supported in Visual Studio's configuration section ---------- ApplicationSettings https://stackoverflow.com/questions/2101273/how-do-i-retrieve-applicationsettings-from-a-loaded-app-config-file/9704380#9704380 The applicationSettings are readonly during runtime. You can set/modify them either via a text editor in the app.config file directly, but it is recommended to open the project properties in Visual Studio and select the "Settings" tab. It is important to set the right scope: If the settings apply to the entire application (for all users), select "Application" as scope. If every user should have individual settings (bound to the user profile), then select "User" For example, if you create myOwnSetting in your project WindowsFormsTestApplication1 as follows: it will add the following to the application's app.config file:

Hi there! Visual Studio creates C# code to access this setting automatically (this is why you should do it in the project properties and not via text editor) - after you have saved the changes, from within the same namespace you can read its value in the application easily via the following code: var currentValue = Properties.Settings.Default.myOwnSetting; Given the applicationSettings in the listing above, this would retrieve the string "Hi there!" for the variable currentValue. Note that if you have created myOwnSetting for the "User" scope, then it is stored in a section named instead of , but you still can access it with the code line above. Another difference of scope "User" settings is that you have read-write access, i.e. it is allowed to do the following: Properties.Settings.Default.myUserSetting = "Something else"; Properties.Settings.Default.Save(); If you try the same with the "Application" scope setting myOwnSetting, it would result in a compile-time error telling you that it is read-only. If you re-start the application, you will notice that myUserSetting has changed to the value "Something else" - but the old value is still in the app.config. Why is this so? The reason is that it is regarded as a default value - and as I said earlier, the "User" scope is bound to the user profile. As a consequence, the value "Something else" is stored in C:\Documents and Settings\USERID\Local Settings\Application Data\FIRMNAME\WindowsFormsTestApplicati_Url_tdq2oylz33rzq00sxhvxucu5edw2oghw\1.0.0.0 in a file named User.config, which looks as follows: Something else You can't exactly tell the path as it is created automatically by the .NET Framework, and it will look different on your PC. But you can see that USERID is the Windows user ID of your current user, FIRMNAME is part of the assembly information you have specified, and the assembly name and version is also used in the path. Note: The with

declaration is mandatory and its name attribute needs to match with the namespace. The namespace must appear exactly once in the configuration, and there is only one applicationSettings section allowed. As you could see in the config file, the namespace is mentioned explicitly there (WindowsFormsTestApplication1.Properties.Settings). As a consequence, if you want to access the settings from code not being in the same namespace you might need to use a fully qualified reference. Having said that, be careful if you copy the entire ... section from one application's config to another - you might need to change the namespace in the target config afterwards. If you're using the Settings Designer (Settings tab in your project), it will create a file named Settings.Settings (along with Settings.Designer.cs to access the sessings via C# code) in the Properties section of your project. This is a copy of the settings as it will be stored in your Web.config or App.config file as well (depending on your project type, only for application scope settings - user scope settings are stored based on the user profile). You can create additional *.settings files and use them (as it is described here). If you're not using the settings designer, or if you're using a tool like LinqPad, you might need to use a different approach. Consider this: internal static string GetApplicationSetting(string key, string nameSpace="Properties.Settings") { string xValue=null; try { string path = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile; XDocument doc = XDocument.Load(path); var xPathStr= string.IsNullOrEmpty(nameSpace) ? "//applicationSettings" : $"//applicationSettings/{nameSpace}"; var settings=doc.XPathSelectElement(xPathStr).Elements().Where( w => w.Name=="setting" && w.HasAttributes && w.Attribute("serializeAs").Value=="String" ); var setting=settings.Where(f => f.HasAttributes && f.Attribute("name").Value==key).Elements(); xValue=setting.FirstOrDefault().Value; } catch {} return xValue; } You can read string type applicationSettings by treating the configuration as an XDocument. The example given is limited to the string type and you can retrieve the setting from the app.config example above as follows: var value=GetApplicationSetting("myOwnSetting", "WindowsFormsTestApplication1.Properties.Settings"); Likewise, you can create a similar function GetUserSetting for the default section: Just copy the code above, rename the function name and replace applicationSettings in the xPathStr by userSettings. There is an upgrade method available for user settings, which is described here. More details about the location where user settings are stored can be found there. The section in the configuration works differently, since it does not distinguish "User" and "Application" scope and it does not support different datatypes, just strings. However, it is possible to easily read and write the configuration keys/values. If you're interested in the code, you can find it here (on stackoverflow): how to read/write config settings of appSettings If you are uncertain whether you should use AppSettings or applicationSettings, then read this before you decide it. ---------- AppSettings https://stackoverflow.com/questions/3638754/how-can-i-read-write-app-config-settings-at-runtime-without-using-user-settings/11841175#11841175 This is the method which allows you to change entries in the : internal static bool SetSetting(string Key, string Value) { bool result = false; try { System.Configuration.Configuration config = ConfigurationManager.OpenExeConfiguration( ConfigurationUserLevel.None); config.AppSettings.Settings.Remove(Key); var kvElem= new KeyValueConfigurationElement(Key, Value); config.AppSettings.Settings.Add(kvElem); // Save the configuration file. config.Save(ConfigurationSaveMode.Modified); // Force a reload of a changed section. ConfigurationManager.RefreshSection("appSettings"); result = true; } finally { } return result; } // function Note that I have found it is necessary to refresh the section appSettings after the update. The function removes a key before it adds it to avoid double entries. This works also if the key does not previously exist. If there is any error it returns false, on success true. The method to read settings is trivial and just listed for completeness: internal static string GetSetting(string Key) { string result = null; try { result = ConfigurationManager.AppSettings[Key]; } finally { } return result; } // function Note that I've surrounded it by a try ... finally block to suppress errors. If any errors occur, then GetSetting simply returns null while SetSetting returns false. That makes handling easier, however if you require the exceptions you can still add catch (Exception) { throw; } to throw the exception up to the caller. Or, for debugging you could add: #if DEBUG catch (Exception ex) { System.Diagnostics.Debug.WriteLine(ex.ToString()); } #endif Which will show the exception in the Output window of Visual Studio if you have selected the "Debug" configuration, but will continue with the code. Note (cross-reference to a similar topic): The applicationSettings section is different, since it distinguishes between "User" and "Application" scope and it supports different datatypes, not just strings. If you want to know how you can handle applicationSettings, you can find it here (on stackoverflow): How to access applicationSettings If you are uncertain whether you should use AppSettings or applicationSettings, then read this before you decide it. If you encounter the warning 'ConfigurationSettings.AppSettings' is obsolete, then this hint can help you. ---------- 20180310 ---------- sample app.config: 1. 直接在App.config檔案中, 改內KeyValue, 就會更新到app.exe.config. 2. 只能放string, 無法strongType 3. 新版本可參考https://blog.miniasp.com/post/2015/11/23/How-Class-library-read-config-from-webconfig-or-appconfig-file.aspx public static uint IoStreamMessageTimeoutInMilliseconds { get { var timeoutConfig = ConfigurationManager.AppSettings["IoStreamMessageTimeoutInMilliseconds"]; if (string.IsNullOrWhiteSpace(timeoutConfig)) { return 10000; } uint timeout; if (uint.TryParse(timeoutConfig, out timeout)) { return timeout; } throw new ConfigurationErrorsException("IoStreamMessageTimeoutInMilliseconds is not a valid int."); } } ---------- t/2015/11/23/How-Class-library-read-config-from-webconfig-or-appconfig-file.aspx ref: https://blog.miniasp.com/post/2015/11/23/How-Class-library-read-config-from-webconfig-or-appconfig-file.aspx