I think you should start off by asking "why are these references service references, instead of binary references?".
There may well be a good reason for this, for example, the service will be deployed to a separate machine to the other projects in the solution. Another reason would be that to the capabilities provided by the service are not a natural fit for running in-process, and would make the consuming application too complex.
In your scenario, the question would be:
"For each of the three service consumers, would it be possible for me to take advantage of the capabilities of the service by simply referencing the service internals via a binary reference?"
If the answer to this is yes then with a little refactoring you can simply remove the WCF service library code and the service references. Then you will simply have three projects which all host the desired capability in-process when they run.
This is desirable for a few reasons, but here are two:
- In-process code is orders of magnitude faster than out-of-process code (like wcf services).
- In-process code is much simpler to manage and deploy.
However, if you do need the service's capabilities to remain wrapped in a WCF service, then you can still simplify your solution dramatically by:
- Moving the service into its own solution, and
- Getting rid of all the service references and using
ChannelFactory<T>.CreateChannel() to call the service directly instead.
ChannelFactory works by allowing you to call a service by referencing the service binaries directly. This negates the need for a service reference, which has no shared binary dependencies.
This approach is desirable for many reasons, but here are two:
- No need to service references, drastically simplifies your code.
- When the service changes, there is no need to update anything; the change is available via binary reference, and is as natural as consuming an assembly in-process.
I often see examples of WCf services included as projects within solutions, where the other projects in the solution consume the service via service reference. This in my mind is not good design. Firstly, a service should never reside under a single solution with it's consumers, and secondly, consumers should consume the service directly and without using service references unless absolutely necessary.
I am not familiar with the process of not using a reference and your
solution looks interesting. I will read up on that
Please do. Service references have no place in a scenario where you are in full control of service and consumers. I know this sounds prescriptive but it is bourne out by experience.
The database model library resides in the BaseLibrary and these are
used by way of reference in the service project
Which of the projects reference this assembly? If the service uses it then you can move it out of the solution with the service. But do the clients also use this? If so, does this mean clients and service both access the same database? If not, then why do they both make use of the same data models?
Would moving services to another solution not negate this advantage of
only having one place for interproject code?
I would strongly disagree that having a single place for interproject code is always a good reason to bunch projects together inside a solution. You can then end up with projects which are completely unrelated to each other (from a business, technology, or capability perspective) sharing a solution just so they can benefit from this "advantage". A better strategy in my opinion is to remove the common assembly into it's own solution, and then publish it to a local NuGet server. Any project which requires this assembly can then retrieve it from NuGet.
