|
this article will help to those people who want to modify the appSettings Paramters value.
|
|
|
|
|
Am i misunderstanding what you're doing though? Writing changes to the configuration file that will apply to all users the next time they restart the app?
I'm not saying there aren't situations where this wouldn't be useful, but perhaps you could describe a few of them... certainly, this is a terrible way to persist any user-specific preferences.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
|
|
|
|
|
Yes May be,
Because this article will helpful , when we are installing Windows application and Set up application Configuration parameters. Because today i faced this problem and found solution for my application, thats why i have posted this article.
i dont know, what you are understanding...
|
|
|
|
|
Jatin Prajapati wrote: i dont know, what you are understanding...
I'm seeing a class that will allow you to write changes to the configuration file for the current app. Not the user settings file, the configuration file shared by all users. And i think that, in most scenarios, this is a spectacularly bad idea. Because it requires the app to have write access to this file, because the changes will apply to all users, because if two users make changes to the same setting only one will "win"...
So. If you needed this for something, or you see a scenario where this would be useful and appropriate, please share them!
I spend nearly every week fighting with 3rd-party code that thinks it's appropriate to write to whatever part of the system they feel like whenever they feel like it. I cannot overstate how severe this problem is, or the danger that comes from encouraging this behavior. So what i want you to do is, explain how this is not a solution for general use, but how in very specific scenarios it might be necessary.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
|
|
|
|
|
Ok, What should i Do ?
|
|
|
|
|
Ok well, i dont know, how many times user will update configuration settings and how many user will update same file at a time. but this Configuration settings is First Time Setup Configuration. Its not like Database application like Add/Edit/Delete every time with Multi user.
that is depend on users requirements. How user want to use Code and for which purpose.
|
|
|
|
|
Jatin Prajapati wrote: Ok well, i dont know, how many times user will update configuration settings and how many user will update same file at a time. but this Configuration settings is First Time Setup Configuration. Its not like Database application like Add/Edit/Delete every time with Multi user.
That's exactly my point: generally, the only time it's appropriate to write to this file is during installation, where it will be created with the defaults or maybe system-specific settings will be written to it. If system-specific configuration is necessary (that is, something more involved than XCopy-deployment is needed), then the installer will modify the config file as is appropriate. But for day-to-day use, the program should take care not to do what this code enables.
I'm not omniscient. There are probably sane scenarios where an app writing to its config file are needed. But i think it's important to approach such a scenario with a heavy amount of skepticism, because if at all possible they should be avoided. And i'm not convinced yet that you actually have such a scenario in mind - hence my request that you describe what you actually intend to use this class for, with a full explanation of why it is necessary.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
|
|
|
|
|
yes sure, thanks for you suggestion. Will Dafenately do this.
|
|
|
|
|
Reading the above, i do have a good use for this way of working. If it is appropriate / the right thing to do is up to all of you, and comments are welcome.
Our company uses deployment software for the distribution of application software. But depending on location/country another sql database connection (read another server) is used. Defaults will only be sufficient if all locations are known in the beginning, and that is not always the case. If however the setting is changed, it's changed for all users in that country/location, and not for a seperate user, so :
In my humble opinion using this kind of code in combination with our deployment software, the installation and configuration can be handled, on installation level, but my program/setup stays the same. (Info : The deployment software then handles the input of the form during installation on the background).
Other ways to handle the above ? Samples / Documentation is very welcome
According to my calculations, the problem does not exist
|
|
|
|
|
First, thanks to post message here.
once, i have wrote this article, people are saying, its not proper way to modify the app.config file, but they are not getting the scenario behind it. and what problem they are facing during Deployment of application.
|
|
|
|
|
chris1969 wrote: Other ways to handle the above ?
If it's not feasible to perform this configuration automatically, then i'd say it is appropriate to require a user with sufficient permissions on the machine to configure it manually. So long as the program doesn't request write access to the file under normal operation, this should work just fine.
Again - my point isn't that there aren't scenarios such as this (where you're rolling some of the installation tasks into the app itself, presumably for convenience); it's that they need to be dealt with carefully. What seems to work beautifully on the dev machine, where you're running as Administrator with access to everything... can easily cause a great deal of headaches when installed on a box where most users can not write to the installation directory. So the question then becomes, how does your program deal with that? Disable the option? Allow it to be changed, but refuse to save the changes? Crash?
That's all i'm getting at. Unless you know that you aren't going to run in a multi-user environment, and know you'll never be used by a limited user account (and both of these bets are becoming increasingly sketchy with each new release of Windows), you'll have to handle them in some way, or you'll find yourself with some very unhappy users. I've been there, trust me, you want to put the thought in ahead of time.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
|
|
|
|
|
|
Shog, I think you are REALLY missing the point and I can give you an excellent example of where this kind of code is MOST useful.
First, I am presuming that you are a bit of a Microsoft "purist" - that is, they build the tools, say "use them this way" and you follow that. I do respect that a little bit, but lets be honest about too - Microsoft has a 30 year reputation for taking the most simple things and making them OVERLY complex often for no good reason. I think this configuration stuff is an EXCELLENT example and I say this because we have been dealing with a problem with their stuff for about two months now. Every document they send us to usually begins with "this is simple" and then they go on and on with layer after layer of useless complexity. But... Let me dive into the example...
We inherited a .NET application written very early on, and to some degree very poorly where the developer writes all his config stuff, user or app, the same folder where the app is installed. In fact, he writes most of the stuff (user or app) into the app.config. Now, as you might guess, as soon as we install on Vista or Win 7 - BABOOM!!! Things go haywire. So, we studied the MS documentation for this stuff and slowly came up to speed on it with one question... (that we actually asked MS support)...
If App.Config is for the application, why would you make it un-writable when so many installs have to gather SQL connection information AT INSTALL, NOT AT SHIPMENT of product, but AT INSTALL. SQL connection strings are App level stuff, NOT user level.
Well, as you might guess MS told us that when they first released this stuff they had a "duh" moment and realized, oh yeah, this aint going to work, and as you probably know, they then added the SQL connection stuff directly, AS AN AFTERTHOUGHT.
So... In our situation we DO need to write to App.Config (for the time being) because we have a huge legacy App that we cannot start re-writing yet because we would have to "detach" all sorts of other code and re-write that, and as you likely know, you cant do that kind of work piece-meal. So, what Jatin presents DOES have a valid place, and a valid case out there.
Yes, in a more perfect world of new development, YOU are absolutely correct. But how much new development is done versus poor tortured developers like us who work for companies that MUST keep the old apps running - and must somehow work around Microsoft's as-usual stupid presumption that we are all just writing brand new glorious code each time they release something.
Jatin stated in his article that this would be good for first time install - and if you have ever worked with truly horrible code that cant be torn apart and re-written in a few days - well, he is doing the community a service.
A couple other points... All this complexity MS had thrown in there... What happens if, like us, you are producing apps that have no user based config and are always installed and controlled at the APP level? Now you have to go through all these hoops for the user stuff, when you dont need one bit of it. We asked Microsoft this, and do you know what they said? "We have to plan for the most complex..." Yeah, great response. Try flying the Space Shuttle to your local grocery store. Trust me, it will take you longer and be more expensive than a simple skateboard. Microsoft does it again!
As well, MS touts "security, security, security..." Really? Well, we encrypt just about every config setting in .NET encryption that MS is proud to point out has never been broken. So if we can do that - why do we then need to go through hoops just to do a simple config file??? Those of us around here miss the days of simple INI files - wonder why?
Jatin presents a good article that IS useful and DOES apply - especially if you ever inherit an old, crappy, poorly written, barely documented application. Give him credit for that. And then, with respect to Microsoft purists - if you want to complicate your life for no other reason that pure complexity, I suggest you try driving your car in reverse everywhere you go. Thats kind of like what Microsoft does each and every day - for what reason? Even they dont know.
Good work Jatin, good article too. Not for everyone - but for those who need it, very helpful. Cudos!
|
|
|
|
|
I'm running across a similar problem. To my knowledge there is at least one scenario where you should modify the .config file. One that I have come across is when there is a connection string to a database. This is stored as an application-scoped setting(for good reason). But what about after deployment? You need to be able to modify the connection string, or not use it at all in your development process, which will take you more time. You could say that you should change the connection string on installation, but what if the database for the app is changed? Why require a re-install when it's just the connection string that needs to be changed?
If there is a best-practice for the above scenario, please explain.
|
|
|
|
|
I do beleive that this situation is helpful in a scenario where connection to two diffrent but identical databases are involved. lets say one database is a live production database and the other is an identical dummy training database. At runtime usere must choose which which database the user wants to conect to. I see no point in having two diffrent apps made when evrything else other than a connection string value in the app.config file is identical.
Faisal
|
|
|
|
|