.NET Core 多框架支持(net45+netstandard20)实践中遇到的一些问题总结

.NET Core 多框架支持(net45+netstandard20)实践中遇到的一些问题总结

前言

本文主要是关于.NET Standard 代码 在多框架 和 多平台 支持自己实践过程中遇到的一些问题和解决办法，希望给遇到这些问题的同学一点参考和思路。问题基本上都是提在 博问 和 Stackoverflow 中，不乏很多大佬都提供了解决问题的思路。接下来则是正文。

问题1：如何发布多个 TargetFramework 的nuget 包

问题来源 ：主要是因为之前的类库只提供了 .NET Standard2.0的版本。很多用户反馈在 .NET Framework 下面不可用，于是有了这个问题。

1.2 问题描述：

在.csproj 文件中声明了

<TargetFrameworks>netstandard2.0;net471</TargetFrameworks>

但是用dotnet pack 命令发布时一直报以下的错：

error MSB3644: 未找到框架“.NETFramework,Version=v4.7.1”的引用程序集。若要解决此问题，请安装此框架版本的 SDK 或 Tar
geting Pack，或将应用程序的目标重新指向已装有 SDK 或 Targeting Pack 的框架版本。请注意，将从全局程序集缓存(GAC)解析程序集，并将使用这些程序集替换引用程序集。因此，程序集的目标可能未正确指向您所预期的框
架

然后安装 net471的框架也安装不了，请问如何解决？
遇到的问题是：项目依赖的是.net standard 2.0 ，但是用户用的是 net461， netstand 的方法net461没有，导致程序报错！

1.3 解决办法:

在.csproj 文件中编写如下

<TargetFrameworks>netstandard2.0;net471</TargetFrameworks>

这时如果你编译，或许会遇到System.Web 冲突的问题,或者是System.Web.HttpUlitity 在上下文中不存在。然后加入下面这句

<ItemGroup Condition=" '$(TargetFramework)' == 'net471' ">
    <Reference Include="System.Web" />
  </ItemGroup>

就可以完美build 了，就解决了该问题了。
还有.net framework 4.7.1 框架装不了的原因也找到了，是因为我用错安装包了，没有下载 developer 的版本，正确的地址是
https://www.microsoft.com/en-us/download/details.aspx?id=56119 然而我用了这个 https://www.microsoft.com/en-us/download/details.aspx?id=56116

问题2：多个TargeFramework 导致关于Nuget包引用的问题

问题来源：这个问题是因为自己打包生成时的一个坑，忘记添加 Assembly Version了，导致发布出去的包找不到引用的程序集。

2.1 问题描述：

关于 Nuget 包解析的，有个最近项原则， 详情可参考NuGet 如何解析包依赖项 用一张微软的图来解释就是：





这个时候会选择最近的那个包，也就是 2.0 版本的。这没问题。
今天遇到的一个问题是，我的一个Nuget包（称之为 Package A 当前版本为 1.2.3 ）本来只支持 netstandard 2.0 的版本，csproj 文件中的定义为

<TargetFramework>netstandard2.0</TargetFramework>

我有另外一个产品ECS Nuget 包（称之为 Package B 版本为 1.0.0），Package B 需要引用 Package A，
关系路线为 【Package B 1.0.0】 -> 【Package A 1.2.3】
这时，程序中调用这两个包可以正常使用的。
后来，由于对 .net framework 的支持，我把原本 Package A 的nuget 包修改了，改成了如下

<TargetFrameworks>netstandard2.0;net45</TargetFrameworks>

Package A 包生成版本为 1.3.2，这个时候，我再引用上述两个包，发现编译没问题，但是在运行时报错了。




我通过升级 Package B 可以解决上面问题，但是为什么会出现这个错误呢？是因为使用了 TargetFrameworks ？还望大佬们指点指点

2.2 解决办法

对比一下 publish 文件夹中的 .deps.json 文件

按照这个思路，有了点眉目，也发现了一个程序中的Bug
第一张图使用老版本的Core，生成出来的deps.json



可以看出 AssemblyVersion 和 FileVersion 都为空，但是通过 runtimeconfig.json 文件可以找到 AssemblyVersion 和 FileVersion 为空的 dll。难道是因为 AssemblyVersion 和最开始的 1.3.2 文件不匹配导致的吗？

"aliyun-net-sdk-core/1.3.2": {
        "dependencies": {
          "Serilog": "2.5.0",
          "Serilog.Exceptions": "4.0.0",
          "Serilog.Sinks.File": "4.0.0"
        },
        "runtime": {
          "lib/netstandard2.0/aliyun-net-sdk-core.dll": {
            "assemblyVersion": "0.0.0.0",
            "fileVersion": "0.0.0.0"
          }
        }
      }

下面是重新生成后的 deps.json 文件，可以正常运行之前低版本的项目包。






结论： 由于 引用的 1.3.2 版本， 然而 CLR 在加载程序集时，找不到 Version 为 1.3.2 的DLL，于是就找原本项目引用的 1.2.3 版本，没有找到，于是报错。理清楚了。

问题3：target framework 为 .net 45 的项目，可以在 Linux 系统下编译吗？

问题来源：Linux上无法打包net45似乎是很正常的事，之前都是通过 windows docker 镜像打包好，然后推送到 nuget，但是由于公司网络的限制以及互通性上会有点问题，关于 .NET SDK 程序集的打包就遇到了无法在 Linux上打包 net45 程序集的问题，通过在 Github上跟踪 Issue，终于发现了解决办法。具体如下：

3.1 问题描述

Target Framework 为 .net framework 4.5 的项目，可以不可以在 Linux 下 dotnet build 生成 net45 的dll 和 运行 dotnet pack 打包生成 net45 和 netstandard2.0 的包?

3.2 解决方案

答案是可以的，哈哈。微软在Nuget针对这个专门发布了一个Nuget包，想要查看详细 Issue 的可以在这里查看 https://github.com/dotnet/designs/pull/33


Nuget上面包的地址为: https://www.nuget.org/packages/Microsoft.NETFramework.ReferenceAssemblies/1.0.0-preview.2


只需要在你的csproj 文件中修改添加如下即可：

<PackageReference Include="Microsoft.NETFramework.ReferenceAssemblies"
                  Version="1.0.0-preview.1" 
                  PrivateAssets="All" />

已在服务器上测试过：具体csporj 配置可以参考 https://github.com/aliyun/aliyun-openapi-net-sdk/blob/master/aliyun-net-sdk-core/aliyun-net-sdk-core.vs2017.csproj

如果有表述或者难以理解 以及 可以改进的地方，麻烦大家提出来。进行交流和讨论。

PS：还有一个就是中文Windows 操作系统中，想要在终端上让异常信息已英文的形式显示，需要更改系统的语言，使用
Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;
Thread.CurrentThread.CurrentUICulture = CultureInfo.InvariantCulture;
在有些情况下以英文显示，有些还是以中文显示。比如 WebRequest 返回的 WebException 就会以中文显示，改一下操作系统语言则正常。