c# - .NET Core WCF Connected Services 中是否有同步方法？

Question

我的 .NET Core 项目只为 WCF 服务生成异步方法。有什么方法可以像在常规 .NET 项目中那样使用同步方法吗？

在常规的 .NET 中，同时存在同步和异步方法，例如:WcfClient.MethodName 和 WcfClient.MethodNameAsync

在 .NET Core 中只有 WcfClient.MethodNameAsync

这个问题帮助了我: How to call asynchronous method from synchronous method in C#?

但是这个解决方案会导致其他问题。对如何生成同步方法/函数有任何想法吗？

Answer 1

检查 this GitHub issue ;他们讨论了一些您可能感兴趣的事实。

You are right. Our NetCore/Netstandard support does not yet include Sync implementation of the APIs.Please note that this change is on our Roadmap as one of the parity items for the transition to .NetCore and we will update with more specific timelines as soon as it is available.

• erezvani1529 commented on Nov 29, 2016

和

Can you clarify for us what your need is for the synchronous methods? Overall, sync is much less resource efficient than async and is not something that we recommend to our customers. You can always use .GetAwaiter.GetResult() if you need to block on the async calls.

We have had some conversations with the CLR team, who provided this guidance:

If you expose an asynchronous endpoint from your library, avoid exposing a synchronous method that just wraps the asynchronous implementation. Doing so hides from the consumer the true nature of the implementation, and it should be left up to the consumer how they want to consume the implementation. If the consumer chooses to block waiting for the asynchronous implementation to complete, that’s up to the caller, and they can do so with their eyes wide open.This is even more important for the “sync over async” case than it is for the “async over sync” case, because for “sync over async,” it can lead to significant problems with the application, such as hangs.

.NET Core 团队出于上面列出的原因(资源消耗等)选择不支持真正的同步 API。即使我们实现了真正的同步，它最终也会在某种程度上同步而不是异步。出于这个原因，我们认为添加伪造的同步 api 对我们的客户来说是一种障碍，而不是帮助。如果您对此有任何反馈，请告诉我们。pemari-msft 评论 May 11, 2017

和

Let me explain the rationale. True sync is not an option for a library if it is consuming a library that does not support true sync, as is the case for us and .NET Core. (And anyway, true sync is something of a misnomer for APIs that make network calls, but that's a different discussion.) So we have two options: create a sync-over-async wrapper, or let the caller do it. But as we have seen, the official guidance and prevailing wisdom is that exposing a wrapper should be avoided. This is with good reason, and it's similar to avoiding an async API that wraps a synchronous invocation. Avoiding such APIs not only keeps the API surface clean, it also avoids confusion. Customers will think there is true support for sync or async and expose this in their own public interface only to discover later that the underlying implementation doesn't actually support it! So we have concluded that it is best to follow the prevailing wisdom in this case.

You are correct that deadlock avoidance is essential, especially in sync-over-async scenarios, so let me say a little about how this is done. The deadlock issue arises when a thread calls an async method and then blocks waiting for the result, while the async method chain is waiting for the thread to free up so it can continue. The solution is to have the async method do its work in a different context where it won't be constrained by a limited pool of threads. This is done internally in the async method using ConfigureAwait, so deadlocks are avoided within the library itself.

If you feel that true sync is important then you can bring this up at https://github.com/dotnet/corefx to get this supported in .NET Core.

• mirobers commented on May 12, 2017

因此，您可以更改项目以避免 Azure 或假同步调用。

然而，2018年，观点发生了变化:

Well, after enough discussion, following the lead set by HttpWebRequest we have decided to offer sync methods as sync-over-async. This is a time buffer for our users before we deprecate the sync APIs in future versions of the library.

@copernicus365 , to keep it simpler for people, particularly those who are already using the library, our Netstandard2.0 support which includes the feature parity between desktop and Netcore, will leave the methods as-is, in the same namespace / binary of the split-per-service packages(split packages are in preview at the moment). Naturally, we’ll need to echo guidance in our docs by the .NET team about the benefits of converting to async, and try to make as clear as possible that it’s sync-over-async under the covers.

Many thanks to everyone who took the time to chime in on this thread and give us feedback!

One related note - for existing people who are already using the sync methods on .NET Desktop, these will also be moving to sync-over-async. We’re modifying the codebase to use HttpClient everywhere (both in desktop and in .NET Core), which doesn’t offer any sort of true sync. This is to get away from having separate implementations of everything (one with HttpWebRequest and one with HttpClient), which has led to many bugs and behavior differences between the different implementations.

• erezvani1529 commented on Mar 16, 2018

这些更改于 2018 年 5 月登陆 .NET Standard 2.0 目标。