Discussion on:

Store .NET application settings in custom XML .config files

This is just like using .ini files in vb 6. Everything is just built in...

Another question.

When you have quite a few users accessing an exe off a network, updating the exe can become difficult because the file might be in use. How does everyone else handle this problem? This is how we do it...
We create two exe's. One for the application and the other one to copy the newest application from the network to the user's machine and activating it...

Any other ideas?

Does anyone else find it ironic that this is basically just an INI file being repackaged as a hot new thing? Not only that, but since it has to be in the same directory and have a specific name, programs are going to break when user's naively try to move them or rename them like they are used to doing!

There may be a way around that, but it wasn't mentioned in this article.

Well sure its neato and all but it is a really limited solution and good only during initial development when you want to offload all those settings somewhere but haven't created your own mechanism to do so. It makes more sense to create this information in the registry so the file can run from anywhere (and if they don't exist then it can simply set default values from hard coded ones within the program), or have the values stored on a web server (or network server) where they can be updated once by an administrator and automatically affect everyone.

To re-iterate and to make it clear that I am not trying to belittle this article, it is my opinion this makes a good quick clean solution to offloading configurable settings during initial development but may not be the best solution in your final product.

Besides, and this may have changed in .Net so correct me if I am wrong, but for an application to be considered "Windows Logo Approved" it must load all configurable settings from the windows registry and not .ini (or in this case .config) files.

One of the selling points for I .Net that I always heard was it's drag and drop deployment. As a newbee in the web development arena, I find that to be a plus. The skeptic in me, however, is having his initial fears verified. Slowly but surely it SEEMS that we are returning to some of the same old limitations and tactics - if we resort to using the registry to hold our configurations that is. I like the configuration files because seems to lean more toward the drag and drop deployment that I first heard of. I do have one question though. If you add connection string info into this file, what type of security should be set so that Zacker the Hacker can't just open up your configuration file, which is auspiciously named after the executable,and read your connection information?

Well if you're talking about a Web application, don't configure IIS to serve up .config files. Microsoft stores config information in web.config that goes in the virtual application root. Its at least as secure as global.asa was.

-Dave

I find it funny that they posted an article on something that serves little purpose other than a place to put your connection string or other machine-specific items.

I don't think you get it. Have you ever used Dynamic properites in Visual Studio.NET? Guess where it stores the dynamic property? Thats right, in app.config! Now you can modify the runtime behavior of your application even after it has been deployedwithout recompiling. Way cool!