Got quite a few responses to my earlier post about the alleged forthcoming demise of the Registry. Instead of just replying on my own thread, I think its worth creating a separate post for this.
In reply to the comments on config files being the INI files i referrred to, actually i was referring to WIN.INI and SYSTEM. INI. At least they were centralised, which is more than can be said for config files (especially if there is shared information)
Basically, I think config files are fine, but they can become very unwieldy especially for DLLs that have a large number of calling apps. <xyz>.DLL.config does not work. Some people have written on other sites that they have managed to make this work, but i dont believe it. Either it works for everyone or it doesnt.
In my current project , I have a big DLL with lots of functionality and most of my settings are in the Registry as there are web services, console apps and windows apps that consume this DLL and Im not going to replicate common config info across all those app/web config files. It would be a nightmare to maintain.
As it is I'm using the EMAB and every client app has to have the EMAB configuration info held in its config file. I havent taken the step of customising the EMAB to read from the registry yet, although I think that will have to be the way forward, or else I have to put all config data on to a standard place (say, Program Files / Common) and read from there.
I had other problems when I tried to put multiple custom config sections in my config files. It just didnt work. I read a ton of articles on the net but none of them were useful. I had exceptions thrown all over the place. The NVC reader would read from the first config section but would stop there and not read further. Thats why I just threw all that away and stored the data in the registry.
Another thing which is beginning to bug me is that I have lots of NUnit test projects (for the various components of the solution) and they have ended up sharing some common config info retrieval. Since they are all console apps, i have used config files, but the replication is annoying. I am not sure if I should abstract the config info into one place and have all the test projects use this common TestDataRetriever component. After all, tests are supposed to be independent. Or is the independence only meant for individual tests and not for test projects ? How do the other folk on this forum manage large test projects?