在另一个项目 c# 中使用引用项目的 WCF 服务

Question

I am struggling to understand certain referencing aspects when it comes to WCF and normal references. I have a solution with 4 projects. One project is services and the other three had service references to this project. One project is a base class library that is traditionally referenced in the other three.

I had to update service references in a certain order or VS would get confused about ambiguous references. This was due to the WCF reference being somehow imported through the normal reference so there were two namespaces for everything service related.

I tried to tidy this up by removing service references from all but the base library so this would be the arbiter of WCF connections and no more ambiguity. However I am not sure it is even possible to use a service reference inside another project by way of reference and the services are throwing an endpoint not found exception. I made sure the projects still had end points but they now do not have the references. I assumed the endpoint would come through with the base reference but it appears it is not. Now classes in the base library are also in conflict between the base version and the service version of them.

Basically the references go a little like this:

WCFProject ->serviceReference<- BaseLibrary ->reference<- SiteProject 1 and 2.

How do I get SiteProjects to use WCF services without the service reference in the home project but the one in the BaseLibrary?

Answer 1

对于那些偶然发现这一点的人，我找到了一种使用以下 SO 线程使用引用项目服务引用的方法： 找不到默认端点元素

Answer 2

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:

1. In-process code is orders of magnitude faster than out-of-process code (like wcf services).
2. 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:

1. Moving the service into its own solution, and
2. 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:

1. No need to service references, drastically simplifies your code.
2. 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.