locked
Handling app.config and web.config in web services based application RRS feed

  • General discussion

  • Hello,

    I am back with a better formed approach I hope. Background, I've inherited a massive solution as I've said before, some 200 projects in the solution. We've got a web services based application that I want to run in either Debug or Release mode, and host the Web Services and Web References accordingly throughout the solution.

    We're running Visual Studio 2010, which we can put the Xml Transform features to good use in the Web Service web.config's easy enough it seems. Then transform the elements which pertain to one mode or the other, including the Location (i.e. either localhost or the production Uri).

    Then we've got Web Service client assemblies which establish Web References to the Web Services. This has got me somewhat stymied at the moment. It's simple enough to establish the Web Reference for the *currently running Web Service*, but how in the world do we set that up to build in either Debug or Release mode?

    One thought is: we abandon the automated Web References altogether and, but for some stubbed proxy code, come up with a more contextualized way of dealing with Build Configuration. How we precisely do that I don't know. Can it be done with Xml Transform like with the Web Services? Or do we need to come up with another way, like using configSourced app.config sections? Or more RYO than that even?

    Then we have the application(s) themselves. Here I think I can leverage a combination of either Xml Transformation and/or configSourced sections and/or appSettings files sort of approach. The tricky part about this is, I've partly confirmed that sometimes my entry points aren't always the WinForms or Console executables that I think they are. Sometimes we late load Class Library resources that are the entry points.

    So... My thought is that we establish a known app.config across the entire solution that we know to be predetermined and setup an AppDomain proxy to interrupt that process and configure to that predetermined app.config. That way we avoid any confusion, we'll just know that where ever we are in the solution, at any given moment we know what app.config we're dealing with ahead of time and eliminate any possibility of confusion or missing something in translation.

    Thoughts? Recommendations?

    Best regards,

    Michael

    Thursday, May 31, 2012 1:51 AM