小编hwa*_*ien的帖子

在 C# 5 引入异步编程的asyncandawait模型后，C# 社区达成了命名约定，为返回可等待类型的方法添加“Async”后缀，如下所示：

interface Foo
{
   Task BarAsync();
}

许多静态代码分析器（基于 Roslyn 和非基于 Roslyn 的）已经被编写为在检测异步编程的代码异味时依赖于这个命名约定。

现在 C# 8 引入了异步可枚举的概念，它们本身不可等待但可以与 结合使用await foreach，命名方法返回似乎有两种选择IAsyncEnumerable：

interface Foo
{
    // No "Async" suffix, indicating that the return value is not awaitable.
    IAsyncEnumerable<T> Bar<T>();
}

或者

interface Foo
{
    // With "Async" suffix, indicating that the overall logic is asynchronous.
    IAsyncEnumerable<T> BarAsync<T>();
}

是否有关于上述选项的明确命名约定指南（来自 C# 语言团队、.NET 基金会或其他权威机构），例如 C# 5 命名约定如何明确标准化而不是留给程序员基于意见的判断？

我正在使用 C# 为仅在台式计算机上运行的 Windows 10 开发 UWP 应用程序，目标平台版本为 10.0.14393.0。由于业务需求，应用程序生命周期必须像传统的 Win32 应用程序一样运行。

因此，我按照本文中的建议请求ExtendedExecutionSession 使用ExtendedExecutionReason.Unspecified. 我还将 Windows 配置为从不休眠和从不休眠。

尽管如此，在极少数情况下，Windows 将有理由撤销扩展执行会话，SystemPolicy然后继续暂停 UWP 应用程序。

两个问题：

1. 我如何获得更多信息（系统日志？事件日志？）关于是什么导致 Windows 撤销扩展执行会话？
2. 如何摆脱这些罕见的暂停情况，以便 UWP 应用程序生命周期的行为与 Win32 应用程序完全一样（即，保持运行直到用户明确停止运行）？

谢谢！