Using multiple ServiceReferences.ClientConfig files?

Topics: Prism v2 - Silverlight 3
Apr 6, 2010 at 7:16 PM

0 vote down star

I'm building a modular Silverlight application, using Prism.

In the Shell project, I'm loading 2x modules, each hailing from a separate assembly. For convenience let's call them ModuleA and ModuleB

ModuleA makes calls to WebServiceA. A ServiceReference.ClientConfig file is present in ModuleA's assembly.

In order for this to work, in the shell project, I've added an "existing item" (path set to the forementioned config file in ModuleA's folder) as a link. The shell launched and the ModuleA made a successful call to the WebServiceA.

Currently, I'm working on ModuleB, it also needs to make webservice calls, this time to WebServiceB. The service reference has been added, and a ServiceReference.ClientConfig file has appeared in ModuleB's assembly. I've attempted to add that config file as a link to the shell project as well, but I've failed.

Q1 : Is it possible to use multiple ServiceReference.ClientConfig files like this?

Q2 : Are there any best-practices for this case?

Q3 : Is it possible to rename a *.config or *.ClientConfig file ? How is it done? How do I tell the application what file to use?

Apr 7, 2010 at 2:32 PM

Hi MaciejM,

My recommendation would be to abandon using ServiceReference.ClientConfig files altogether and follow the approach proposed by David Betz in the 2 articles below:

http://www.netfxharmonics.com/2008/11/Architectural-Overview-Creating-Streamlined-Simplified-yet-Scalable-WCF-Connectivity
http://www.netfxharmonics.com/2008/11/Understanding-WCF-Services-in-Silverlight-2

My team and I started using ServiceReference.ClientConfig in a SL Prism project but it quickly grew too difficult to manage - especially when promoting a deployment to an environment close to production (i.e. Dev -> QA -> Staging -> Prod). Every promotion to a new environment meant we needed to manually go in and modify the ServiceReference.ClientConfig with the correct WCF settings for the environment - a process that was very error prone.

HTH,

Ryan