• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

.Net Configuration Files Nightmare

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    .Net Configuration Files Nightmare

    Each project I work on seems to do configuration in a completely diffrent way to the previous one. The current website I'm working on uses the Settings class which is deserialised from the app.config file. It means we've got settings all over the place as there is one of these for every library project in the app. Now I'm going to compicate things further because it would appear that I can't add anything in here other than simple string values and connection strings - I want to add an SQLCacheDependency section but this mechanism doesn't seem to handle it at all so I'll stick it in the web.config and get at it from the System.Configuration.ConfigurationManager.OpenExeC onfiguration. I'm thinking that there must be a way using this settings class to handle more complex settings but I'll be buggered if I can find anything out there.

    I preferred the concept of just having one config file for the host process & all dependencies accessing it from some shared custom config class.

    #2
    Only the final system should have a config file. All config should go in here. You can facilitate this but putting common config in external files and including them.

    Class libraries shouldn't have config files directly as they aren't executed - although an example config file for down system use wouldn't be a bad idea.

    Comment


      #3
      Originally posted by themistry View Post
      Class libraries shouldn't have config files directly as they aren't executed - although an example config file for down system use wouldn't be a bad idea.
      But they do by design now - don't know since what version of .Net this has been happening but if I create a data access layer library and create a new datasource in the designer, it will stick the connection details in the app.config for that library. I always take this out and stick it in the web.config & handle it all myself though. I think I'm right in saying that this app.config would never be distributed with the compiled assembly as everything in it is serialised to create an internal settings class for use by that library only.

      Comment


        #4
        Originally posted by wurzel View Post
        It means we've got settings all over the place as there is one of these for every library project in the app.
        You can have a single app.config in the Solution Items folder and link to it from each project. That's what I'm doing anyway. My .dll projects don't reference it, but each dll project has a separate unit test project which does. Of course not all projects will use all the settings.

        Comment

        Working...
        X