WCF comes with a very handy configuration language that allows you to define bindings, end point properties and the like. Doing the same in code is a) tedious, b) inflexible: any minuscule change would require recompilation and redeployment.<\/p>\n
The trouble is, the configuration information is read from the .NET configuration file, which is unconditionally set to This inflexible rule stands in a way of self-contained libraries that use WCF. It is not possible to define WCF configuration on a per library basis, it must be done at the application level. Not only we have a leaking abstraction here, this abstraction may leak into very interesting places. E.g. if you are writing a COM+ component, the configuration file it will use suddenly depends on whether it is in-proc or out-of-proc, and all out-of-proc components may as well end up reading Modular application that load plugins dynamically (along the lines of CAB) face even bigger problem. It is not possible to know in advance what WCF settings will be used by a plug-in, so this information cannot be placed into the application config.<\/p>\n Reading a different configuration file should have been easy, but it is not. WCF is really hardwired to This is only one consequence of Microsoft’s decision to hardwire the configuration to a specific file. In the Java world this decision would probably be unthinkable. Almost everything in Java can be substituted to a different implementation. If it’s not an interface, it’s a system property. .NET, however, pursues a different philosophy (see “Is .NET Really a Java Clone?<\/a>“).<\/p>\n In many cases it is fine, but the decision to hardwire the configuration path is unfortunate and it keeps biting us. Mr. Gates, thou shalt not hard code!<\/p>\n","protected":false},"excerpt":{"rendered":" WCF comes with a very handy configuration language that allows you to define bindings, end point properties and the like. Doing the same in code is a) tedious, b) inflexible: […]<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"Layout":"","footnotes":""},"categories":[3,4],"tags":[],"class_list":["entry","author-ikriv","post-307","post","type-post","status-publish","format-standard","category-dotnet","category-hack"],"_links":{"self":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/307","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=307"}],"version-history":[{"count":0,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/307\/revisions"}],"wp:attachment":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=307"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=307"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=307"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}calling_executable<\/i>.exe.config<\/code>, at least for the primary app domain. This is true even if the calling executable is not a .NET application.<\/p>\ndllhost.exe.config<\/code>.<\/p>\ncalling_exe<\/i>.exe.config<\/code>. Some redirection is possible, but it is quite verbose and complicated (see “Loading the WCF configuration from different files on the client side<\/a>“).<\/p>\n