Visual Studio 2019中用Six Labors ImageSharp遇System.Memory版本错误求助

Q：ImageSharp是否绑定System.Memory 4.0.1.0版本？ #

没错，旧稳定版的Six Labors ImageSharp确实强依赖System.Memory 4.0.1.0，这就是你遇到问题的核心原因——虽然项目属性里显示的是4.0.1.0版本，但NuGet实际安装的是更高的兼容版本（4.6.28619.1），而旧版ImageSharp在运行时会严格校验这个版本号，直接导致找不到指定程序集的错误。

具体解决方法 #

你已经找到的夜间构建版本方案非常有效，这里再梳理细节和另一个可选方案：

• 方案1：切换到ImageSharp夜间构建版本
  夜间版已经更新了依赖规则，把System.Memory的依赖要求调整为>=4.5.3，完美绕过了旧版本的强版本绑定问题。你直接在NuGet包管理器中搜索带有-nightly后缀的ImageSharp版本安装即可，安装后无需手动调整System.Memory版本，NuGet会自动处理兼容的依赖包。

• 方案2：添加程序集绑定重定向（适合不愿使用夜间版的场景）
  如果坚持使用稳定版，可以在项目的App.config或Web.config中添加绑定重定向配置，让运行时将对4.0.1.0版本的请求重定向到实际安装的更高版本：

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Memory" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.6.28619.1" newVersion="4.6.28619.1" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  

  注意把newVersion的值替换成你实际编译后DLL的版本号（比如你这里的4.6.28619.1）。

补充说明：为什么重装System.Memory没用？ #

其实从System.Memory 4.5.x版本开始，NuGet包的版本号和实际DLL的版本号就不再一致了，这是.NET生态中常见的兼容策略，但旧版ImageSharp没有适配这种情况，所以才会出现项目属性显示版本正确，但实际DLL版本不符的矛盾。

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