调用 TimeZoneInfo.FindSystemTimeZoneById() 时出现异常

Question

为什么以下行在 .NET Console 应用程序中成功，但在 ASP.NET Core WebApi 应用程序中失败？

TimeZoneInfo.FindSystemTimeZoneById("Europe/Berlin")

WebAPI 情况下的例外是：

Unhandled exception. System.TimeZoneNotFoundException: The time zone ID 'Europe/Berlin' was not found on the local computer.
   at System.TimeZoneInfo.FindSystemTimeZoneById(String id)
   at Program.<Main>$(String[] args) in C:\Development\TimezoneTest\WebAPI\Program.cs:line 1

---

这两个项目都是同一解决方案的一部分，一个使用 console 模板创建，另一个使用 webapi 模板创建。我在 IDE 中或使用

dotnet run

运行它们。

我知道如何解决问题。我感兴趣的是差异的原因是什么，在一种情况下会导致异常，但在另一种情况下不会。

---

我也知道一个类似的问题，并且接受的答案包含有关注册表信息的提示，但我并不完全理解它，因为我在同一台 Windows 笔记本电脑上本地运行这两个应用程序。

Answer 1

您遇到的问题可能源于两种应用程序类型之间时区信息的初始化和使用方式的差异，即使在相同的 Windows 环境中运行也是如此。

在 .NET 中，

TimeZoneInfo.FindSystemTimeZoneById

依赖于系统的时区数据，在 Windows 上，该数据来自 Windows 注册表。但是，加载和访问这些数据的方式可能会有所不同，具体取决于应用程序的类型以及运行时的初始化方式。

造成差异的潜在原因：

1. 应用程序托管模型差异： 与 ASP.NET Core Web API 应用程序相比，控制台应用程序具有不同的托管模型。 Web API 托管模型可能会以不同的方式初始化运行时，从而可能导致时区数据加载方式的差异。例如，ASP.NET Core 应用程序可能具有更多限制或可能使用不同的配置，导致时区查找的行为不同。

2. 对时区数据的隐式依赖： 当您运行控制台应用程序时，它通常使用比 ASP.NET Core Web API 更少的运行时依赖项和初始化步骤。在 ASP.NET Core Web API 中，附加配置和中间件组件可能会改变系统数据的访问或缓存方式。这可能会影响时区查找，即使在同一台计算机上也是如此，从而导致 TimeZoneNotFoundException。

3. SDK 和运行时差异： .NET SDK 根据应用程序类型初始化事物的方式可能存在细微差别。即使两个应用程序使用相同的运行时，ASP.NET Core Web API 处理与本地化、全球化或系统数据访问相关的依赖关系的方式可能与控制台应用程序略有不同。

4. 注册表访问或权限问题： 尽管这两个应用程序都在本地运行，但它们访问 Windows 注册表的方式可能有所不同。 Web API 可能会在不同的用户上下文、权限集或不同的进程隔离下运行，这可能会阻止它访问控制台应用程序可以毫无问题地访问的相同注册表项。

5. 调试上下文中的环境差异： 当在 Visual Studio 等 IDE 中运行这两个应用程序或使用

   dotnet run

   时，它们的运行时环境可能仍然存在细微差别。例如：

• 不同的项目模板可能会导致使用不同的运行时设置或环境变量。
• Web API 应用程序有时会加载一组不同的环境变量，或者可能在与控制台应用程序不同的上下文中访问系统数据。