这个问题的核心在于禁用自动生成AssemblyInfo后，手动维护的AssemblyInfo.cs与项目文件（.csproj）的元数据配置不匹配，导致运行时程序集标识解析失败，具体可以拆成以下几点来理解：

1. 自动生成AssemblyInfo的默认行为
   默认情况下，.NET Standard/.NET Core项目会通过MSBuild自动生成AssemblyInfo相关的元数据（比如版本、文化、公钥令牌等），这些元数据直接读取自.csproj文件中的属性（如Version、NeutralLanguage）。此时，项目输出的程序集的完整标识（名称、版本、文化、公钥令牌）和.NET Core控制台项目在依赖项中记录的标识完全一致，运行时CLR能准确找到对应的程序集。

2. 禁用自动生成后的潜在不匹配
   当你添加<GenerateAssemblyInfo>false</GenerateAssemblyInfo>后，项目会转而使用手动编写的Properties/AssemblyInfo.cs文件。如果你的手动文件中存在以下情况，就会引发问题：

   • 设置了[assembly: AssemblyCulture("en-us")]（而默认自动生成时会设置为中性文化""）
   • 程序集版本（AssemblyVersion）与.csproj中的Version属性不一致
   • 公钥令牌设置不符合预期（默认是null，但如果手动配置了强签名可能会冲突）
     这些差异会导致输出的程序集标识与.NET Core项目引用时期望的标识不匹配。

3. 运行时依赖解析的严格性
   .NET Core的运行时依赖解析是严格基于程序集的完整标识来查找的。你的报错信息中显示找不到的是MyNetStandard20Assembly, Version=0.1.0.0, Culture=en-us, PublicKeyToken=null，这说明：

   • 你的手动AssemblyInfo.cs中设置了AssemblyCulture("en-us")，而自动生成时会默认生成中性文化的程序集
   • .NET Core控制台项目在构建时，是基于.NET Standard项目的.csproj属性（默认中性文化）来记录依赖的，但实际输出的程序集是带en-us文化的，导致运行时CLR找不到匹配的程序集。

4. 移除配置后恢复正常的原因
   当你移除<GenerateAssemblyInfo>false</GenerateAssemblyInfo>后，MSBuild会重新接管AssemblyInfo的生成，覆盖手动文件中的冲突配置（比如自动设置AssemblyCulture("")、同步版本号），使程序集标识与依赖项记录的标识一致，因此运行时能正常找到程序集。

• 如果坚持要手动维护AssemblyInfo.cs，确保以下几点与.csproj属性完全一致：
  • AssemblyVersion和AssemblyFileVersion与.csproj中的Version属性匹配
  • 不要设置AssemblyCulture（保持为""，即中性文化）
  • 公钥令牌设置与项目的强签名配置一致（如果没有强签名，保持默认null）
• 或者，保留自动生成AssemblyInfo的默认行为，将需要自定义的元数据直接写在.csproj文件中（比如<Version>0.1.0.0</Version>、<NeutralLanguage>en-us</NeutralLanguage>），无需手动维护AssemblyInfo.cs。

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