.NET Core 3.1引用.NET Standard 2.0 NuGet包运行时找不到程序集如何解决

根因分析 #

该异常的核心触发原因是引用的OneCall.FeatureFlags NuGet包存在打包配置错误：

• 包内的程序集被错误标记了Culture=en-US属性，被.NET Core运行时识别为en-US文化对应的附属程序集，而非中立文化的主业务程序集。
• 编译阶段NuGet会正常提供该程序集作为编译引用，因此不会出现编译错误，IDE的智能提示也能正常工作，编译后程序集会被输出到bin目录的根路径下。
• 运行时CLR加载特定文化的附属程序集时，只会到对应文化代码的子目录（该场景下会查找bin\debug\netcoreapp31\en-US\目录）下检索对应文件，不会读取bin根目录下的同名程序集，因此抛出文件找不到异常。
• Fusion Log Viewer默认不记录附属程序集的加载尝试日志，因此排查时无法找到相关加载失败记录。

解决方案 #

方案1（最优，可修改NuGet包源码时使用） #

修复NuGet包的打包配置，移除程序集的特定文化设置：

1. 打开OneCall.FeatureFlags项目的.csproj文件，删除其中的<NeutralCulture>en-US</NeutralCulture>配置项，或者清空AssemblyCulture特性的赋值。
2. 重新编译打包该NuGet包，发布新版本后在调用方项目更新引用即可彻底解决问题。

方案2（临时兼容，无法修改NuGet包时使用） #

在调用方项目的生成事件中添加逻辑，将对应程序集复制到运行时的检索路径：

1. 右键点击调用方项目 → 属性 → 生成事件 → 后期生成事件，添加以下命令：

if not exist "$(TargetDir)en-US" md "$(TargetDir)en-US"
xcopy /y "$(TargetDir)OneCall.FeatureFlags.dll" "$(TargetDir)en-US\"

2. 重新生成项目后即可正常运行。

注意：使用该方案时，生产环境部署需要将生成的en-US子目录连同应用代码一起打包发布，否则线上运行依然会触发相同异常。

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