.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 就会以中文显示，改一下操做系统语言则正常。