Why in Gods great name would you go to the effort of making xml files when you already have a whole entire part of VS dedicated to exactly what you want?
Because some people enjoy not using methods that have limitations?
Let alone an application configuration file does not need to be flooded with every bit of configuration possible.
On larger scale projects the file can become rather large, rather fast.
Understanding how to use other aspects that are included in the .NET framework are not a bad thing.
Originally Posted by LaPanthere
Why in Gods great name would you go to the effort of making xml files when you already have a whole entire part of VS dedicated to exactly what you want?
Just in the same way as you are suggesting to create an xml file VS Project settings does the exact same.
View > [name] Properties > Settings Tab
Code:
My.MySettings.Default.SettingName = Textbox1.Text
No mess no fuss.
Much mess, fuck-tonne of fuss.
It's sure as hell no fun adding 100 properties one-by-one to the Project settings, then retrieving/saving them one-by-one as well. In addition to this, all settings are lost as soon as you move the exe to a new location...great. If that wasn't enough, you can't share settings with other people using the application (i.e if they broke their settings). Use My.Settings sparingly or not at all, for true user config you probably want to use an external file or even a database.
Originally Posted by LaPanthere
Why in Gods great name would you go to the effort of making xml files when you already have a whole entire part of VS dedicated to exactly what you want?
Just in the same way as you are suggesting to create an xml file VS Project settings does the exact same.
View > [name] Properties > Settings Tab
Code:
My.MySettings.Default.SettingName = Textbox1.Text
No mess no fuss.
Because the settings is just a shortcut way of saving settings to your temp folder. If you move the project, the temp folder is designated to the last place your project was at, rendering your settings useless after moving.