In my last few posts I looked at the new options that WCF 4.5 provides for managing the most awkward part of WCF: configuring the services. I looked at the new options for configuring IIS hosted services in code, configuring (from code) service libraries that support multiple endpoints, loading your config files from a central location (in both service libraries and IIS-hosted services).
So what should you do with these new WCF features? I’m still leery of the using code based configuration because, as I move my service from development to test to production, I’ll want to change the service’s configuration. For instance, at the very least, I want all three versions of the service to have different endpoints. I’m also uncomfortable with letting anyone get access to one of my Web Service’s contract just by tacking “?wsdl” to the end of the service’s endpoint. So, while I’ll leave that feature in place for testing, I prefer to turn it off in the production system. Instead, before moving a Web Service to production, I’ll extract the WSDL document, store it some safe place, and make potential consumers request it from me. Among other benefits, that lets me maintain a list of those consumers so I’ll have some clue who I should contact if I make any changes to my Web Service. Finally, while I want to turn to include all the detail in my exceptions in the test version of my service, I want to turn that off in production, also.
If I’m doing my configuration in code (as opposed to in a configuration file), making those changes is harder, though not impossible. If the parameters are all in a configuration file, I can read the current values from the file using NotePad and update them without having to recompile if I need to. Changing my config file means that I don’t need to modify my code as I move the service from development through to production. Often, I will simply create three versions of my config files for development, test, and production, put the files in place, and just not update them during the release process. That way, as the code moves from test to production, it just picks up the config file at the site (that does mean that I need a separate release process on those occasions when I do need to update the config file). But, even then, configuring in code doesn’t really prevent me from doing that: I can just make sure that my configuration code reads in any critical parameters from my application’s settings. That will get me virtually the same benefits as keeping the whole configuration in a file. If I do that, it’s just a matter of managing the application’s settings in each of my development, test, and production environments (and I’m probably doing that already for other parts of my application that are using application settings).
However, I have to admit, that I do like WCF 4.5’s new feature that allows me to programmatically load config files from a central location. That allows me to keep a separate set of configuration files for each of development, test, and production but not have them spread out in several different locations. By keeping my all three versions of the file in one place, the only thing I have to change in the service as I move it from development to production is the name of the file being loaded by my code in the new environment. But, having said that, I’ll probably keep the name of the file in my application’s settings so I really haven’t changed the problem much: instead of keeping multiple pieces of information in application’s settings (address, metadata accessibility, error detail), I’ll be keeping only one (path to the configuration file). If you think managing one piece of information isn’t that more difficult than managing multiple pieces and find configuring your service with code attractive, you may make a different choice than me. However, I will say that, by keeping my configuration in a file, I can make any configuration change I want without recompiling my code—using code means that you can only make those changes that you planned for in writing your Configure method.
Technology is all very good but deciding when and how to use it is “context sensitive”—different value systems will cause developers to make different choices. One of the things I like best about Learning Tree’s .NET Best Practices and Design Patterns course is that it makes that point and lays out the costs and benefits for the best practices it addresses.