我对Metro dev很陌生，我只希望能以一种可以理解的方式表达我的问题......
实际上我正在将旧应用程序的一部分移植到Metro。逻辑部分是一个独立的项目（可移植库），它应该用于1）旧的WPF应用程序和2）新的Metro应用程序。基本逻辑是相同的，但是一些子系统（例如文件操作管理器）必须以不同的方式编码 - 即Metro的异步方式。
我的问题是：我是否必须将整个方法调用者caller-callee重写为新的异步范例？假设我有一个由4个方法组成的链，从方法A = Metro UI事件异步处理程序开始（通过接下来的2个方法，我将它编码为async void，因为它是顶级火灾和忘记事件）和C）放在我的应用程序的不同层，直到方法D包含“await CreateFileAsync”方法（由Microsoft制作异步）。
现在：应该使用await调用异步CreateFileAsync方法。这迫使我也使方法D异步。要从C中调用方法D，从A中调用B和B，我是否必须将所有A，B和C重写为async-await样式？
我可以感觉到我缺少更深层次的知识所以我正在努力教育自己，但同时我想在这里试试运气......
我是否必须重写代码的很大一部分？我的上述陈述是否错误？
非常感谢，汉斯
答案 0 :(得分：4)
我建议您将可移植库重写为异步。它没有以前那么糟糕; Microsoft在async / await上非常努力，以便尽可能轻松地将同步代码转换为异步代码。我希望很多其他人在不久的将来也会这样做，而R＃可能会实现“make async”重写。
混合同步和异步代码时存在非明显的缺陷 - 请参阅Stephen Toub的上一篇博文Should I expose synchronous wrappers for asynchronous methods?因此，我认为将异步操作公开为异步API（以及作为同步API的同步操作）更为简洁）。
更新：如果您确实希望同步代码调用异步代码，则可以使用my AsyncEx library中的Task.WaitAndUnwrapException扩展方法。但是，你仍然有Stephen Toub的帖子中提到的问题，即：
ConfigureAwait(false)，您就会陷入僵局。（2）不再那么常见，但（1）是一种真正的可能性。正在测试async的人定期brought up，因此他们将其与同步代码混合。