In segment 3 4 here of this series, I discovered a distinct problem with Visual Studio's treatment of WCF Library projects. Specifically, any WCF Library project in Visual Studio is automatically hosted in a test harness during a debug session -- even if you have explicitly told visual studio not to start that particular project or deleted any reference to WcfSvcHost.exe in any of the project files!

This caused problems when I was explicitly hosting my service in an outside application (like my WinForm app). If I had the service, service host, and client application in the same VS solution (and who wouldn't?), I couldn't use the same configuration information in the WCF host library as the WinForms host. If I did, one of two would fail to initialize, and it was always my hosting application that started up after the WcfSvcHost.exe application that failed. But, changing port numbers between the projects meant that I couldn't use the automatic "Update Service Reference" tool within Visual Studio without manually changing port numbers before I updated. Convincing VS that this wasn't a WCF Library (by removing the project type guid) meant that the automatic update tool wasn't even an option.

The solution was a side effect of my attempt to re-architect my application for re-use. The "Update Service Reference" tool uses the App.Config file within the project where the service reference lives. The applications use the App.Config within the project where the applications live. So, the simple solution is to extract the service references into a different .dll from the client application like this:

If you do that, then you can change the port numbers in the host application and client application projects without disturbing the port numbers in the WCF Library or the Service Access library. So, the "Update Service Reference" tool continues to work. The WCF service is still spun up twice on a debug session, but only once on the ports listed in the host application's app.config.