使用CultureInfo的DateTime.ToString在LinqPad与VS即时窗口格式不一致问题

这个问题确实很典型——相同的代码在不同环境输出不一致，你推测的DLL版本/加载差异方向完全正确，下面是具体的排查方法：

1. 先确认.NET运行时版本差异 #

不同.NET版本对特定文化的格式规则可能有调整：

• 在LinqPad里直接运行 Environment.Version，查看当前使用的.NET版本；
• 在VS即时窗口输入 Environment.Version 回车，对比两者的版本号（比如一个是.NET Framework 4.7.2，一个是.NET 6，或者同框架但小版本不同）。

2. 对比System.Globalization程序集的加载信息 #

核心的文化处理逻辑在System.Globalization.dll里，要确认两个环境加载的是不是同一个版本：

• LinqPad中：
  运行 typeof(CultureInfo).Assembly.Location 获取DLL的本地路径，右键查看文件属性里的版本号；也可以开启LinqPad的「Advanced」→「Show Assembly Loads」功能，查看所有加载的程序集详情。
• VS即时窗口中：
  输入 typeof(CultureInfo).Assembly.FullName，获取包含版本、公钥令牌的完整程序集标识，和LinqPad的结果对比。

3. 直接验证文化的时间格式模板 #

输出nb-NO文化的具体格式规则，看模板本身是否不同：
在两个环境分别执行以下代码：

var nbNo = CultureInfo.GetCultureInfo("nb-NO");
Console.WriteLine("LongTimePattern: " + nbNo.DateTimeFormat.LongTimePattern);
Console.WriteLine("ShortTimePattern: " + nbNo.DateTimeFormat.ShortTimePattern);
Console.WriteLine("FullDateTimePattern: " + nbNo.DateTimeFormat.FullDateTimePattern);

如果LinqPad里的时间模板是HH:mm:ss，而VS里是HH.mm.ss，那直接就能解释输出差异——模板差异通常来自不同.NET版本的文化规则更新。

4. 检查系统/环境的区域设置覆盖 #

有时候即使指定了特定文化，环境的区域设置也可能强制覆盖：

• 在两个环境分别执行 CultureInfo.CurrentCulture.Name 和 CultureInfo.CurrentUICulture.Name，确认是否有意外的区域设置（比如系统默认区域不是nb-NO，但某个环境开启了区域替代）。

5. 排查DLL重定向或自定义文化配置 #

检查配置文件里的程序集绑定规则：

• 查看LinqPad的LinqPad.exe.config，有没有<assemblyBinding>节点强制重定向System.Globalization或相关DLL到特定版本；
• 检查VS项目的app.config/web.config，或者调试进程是否加载了自定义的文化资源DLL（比如第三方修改的nb-NO文化包）。

通过以上步骤，你就能精准定位到是哪个环节导致的格式差异了。

内容的提问来源于stack exchange，提问作者AndrewR