Am I the only C# develeoper who HATES web config files....?
-
These files are a pain to work with, are full of meaningless gibberish, and we are expected to add this guff without any support from Visual Studio... Does anyone know every section and item that a web config file can hold?
-
Try keeping up with INI files. :-\
When you are dead, you won't even know that you are dead. It's a pain only felt by others. Same thing when you are stupid.
.ini files, specific to each application, make a lot more sense than one big registry. If an INI file gets screwed, only one app is screwed. If the registry gets screwed, your whole OS is screwed. If they get too big, then a good INI-specific editing tool is needed, but it's still easier to maintain and understand than the registry. MS should have abandoned the registry long ago.
If you think 'goto' is evil, try writing an Assembly program without JMP.
-
.ini files, specific to each application, make a lot more sense than one big registry. If an INI file gets screwed, only one app is screwed. If the registry gets screwed, your whole OS is screwed. If they get too big, then a good INI-specific editing tool is needed, but it's still easier to maintain and understand than the registry. MS should have abandoned the registry long ago.
If you think 'goto' is evil, try writing an Assembly program without JMP.
At one time, there was win.ini / system.ini Shove EVERYTHING IN THERE. == Crash == Okay, every app gets it's own INI file, we have learned apps require more data than can be properly stored in an INI file (was it like 16K)? == Boom == We have a SINGLE registry. It can grow as needed, put everything in there! (Ignore the 3 minute login, roaming profiles (OMG) and other stuff) == Bang == So now we have Registry for SOME Things, INI Files for other things, and config files for other things. and MANY require some combination of all of them! In the end, property bags (some kind of complex XML/JSON configuration file is what is required). They should be application specific, and WELL-DOCUMENTED by the VENDOR. And how you add your own stuff should be VERY VERY CLEAR. I hope we get there... Before I retire.
-
Bring back JCL!
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
The Java Command Line?
-
At one time, there was win.ini / system.ini Shove EVERYTHING IN THERE. == Crash == Okay, every app gets it's own INI file, we have learned apps require more data than can be properly stored in an INI file (was it like 16K)? == Boom == We have a SINGLE registry. It can grow as needed, put everything in there! (Ignore the 3 minute login, roaming profiles (OMG) and other stuff) == Bang == So now we have Registry for SOME Things, INI Files for other things, and config files for other things. and MANY require some combination of all of them! In the end, property bags (some kind of complex XML/JSON configuration file is what is required). They should be application specific, and WELL-DOCUMENTED by the VENDOR. And how you add your own stuff should be VERY VERY CLEAR. I hope we get there... Before I retire.
Kirk 10389821 wrote:
I hope we get there... Before I retire.
A beautiful plan, but I'm not holding my breath for MS to give up on the registry. With any luck I'll retire in 7 years. I can probably suffer with the status quo that long.
If you think 'goto' is evil, try writing an Assembly program without JMP.
-
These files are a pain to work with, are full of meaningless gibberish, and we are expected to add this guff without any support from Visual Studio... Does anyone know every section and item that a web config file can hold?
Remember, these configuration thingies, including dependency injection and other modern architectures, are for turning your glorious compiled language into BASIC. Not even into Visual BASIC.
-
In a word: no.
98.4% of statistics are made up on the spot.
BINGO! Finally someone who understands how to answer a question. Thank you, kind Sir.
-
At one time, there was win.ini / system.ini Shove EVERYTHING IN THERE. == Crash == Okay, every app gets it's own INI file, we have learned apps require more data than can be properly stored in an INI file (was it like 16K)? == Boom == We have a SINGLE registry. It can grow as needed, put everything in there! (Ignore the 3 minute login, roaming profiles (OMG) and other stuff) == Bang == So now we have Registry for SOME Things, INI Files for other things, and config files for other things. and MANY require some combination of all of them! In the end, property bags (some kind of complex XML/JSON configuration file is what is required). They should be application specific, and WELL-DOCUMENTED by the VENDOR. And how you add your own stuff should be VERY VERY CLEAR. I hope we get there... Before I retire.
-
These files are a pain to work with, are full of meaningless gibberish, and we are expected to add this guff without any support from Visual Studio... Does anyone know every section and item that a web config file can hold?
-
These files are a pain to work with, are full of meaningless gibberish, and we are expected to add this guff without any support from Visual Studio... Does anyone know every section and item that a web config file can hold?
I hate config files of any description
-
These files are a pain to work with, are full of meaningless gibberish, and we are expected to add this guff without any support from Visual Studio... Does anyone know every section and item that a web config file can hold?
You think the default web app web.config files are bad in their vanilla form, just wait until you have to deploy into a secure environment. The Web.config is just one link in an inheritance chain that flows down from %WinDir%\System32\intetsrv\config\Applicationhost.config through each application directory to your web site's directory. You haven't lived until you've had to walk every config file in this chain to find the one that has a duplicate ISAPIRestriction or Authentication tag definition (this breaks the entire IIS worker process).