上篇（.Net基础体系和跨框架开发普及）介绍了.Net当前生态下的大概情况，也分享了简单实现的过程，这篇文章就是讲解我的OSS.Common项目扩展.Net Standard 支持的过程，主要集中在：方案的选择，移植检测，移植过程，常见问题的解决思路，以及nuget的打包部署这几个方面。

　　在开始之前简单介绍下OSS.Common项目的涉及的内容，方便了解后边所遇到的问题。这个类库是相对简单的一个基础类库，提供主要有以下的内容：1. 基础用户系统设备信息实体定义，2. 主流加解密方案实现（md5,aes,sha1,hmacsha1）， 3.  常规实体DTO转化，静态扩展方法（时间，字符串等等处理）， 4. 基础日志，缓存，异步辅助静态类及默认方案实现（采用了简单Provider模式，使用者可以注册自己的实现方案）， 5. 全局结果，分页实体定义。　　其主要作用就是完成对常见碎化方法的收集规整，方便在业务逻辑中减少不必要的消耗，了解之后我们进入具体的扩展过程。

　　一. 方案的选择

　　这个其实在上篇文章中已经做了介绍，当前.net core ，.net Framework，mono for Xarmain等都有自己的运行时，虽然使用的都是C#语法，但是类库在不使用可移植或者标准库的前提下不能直接互相调用。随着.net standard 2.0的即将推出，.net core（asp.net core） 的应用场景会越来越普遍，对旧有项目的兼容需求会越来越强烈，oss.common也是遇到这个问题，所以我将对它进行.net standard支持的扩展。

　　由于当前项目现在在好几个.net framework的项目中还在使用，为了旧项目中对net45的版本的支持不能丢失，所以我会保留两套解决方案，一个为.net Standard 提供支持，一个为.net framework使用，两个类库项目，共享同一套代码文件，针对Framework特有功能通过条件编译来控制。github上目录结构已更新，欢迎查看。

　　二. 移植检测

　　在移植之前我们需要对移植有个大概评估，了解需要代码改动的覆盖面积，确定代码的可移植性，这里推荐使用微软官方提供的移植检测工具（ApiPort），或者使用它的VS扩展。这里我使用的是vs插件，安装完插件之后，打开解决方案，查看右键菜单会有如下两个选项：

　　首先，点击第二个选项，配置要检测的移植对比版本，如下图：

　　完成对应的检测版本之后点击确定，点击第一个选项，执行分析过程，会生成html和xsl两种报表，html报表界面如下所示：

 报表中会给出对应版本的接口覆盖情况，以及相关的建议，可以说是比较详细了。

　　三.移植过程

　　经过上边的检测，可以看出oss.common项目 在.net standard1.4下，大概超过20%的代码不能直接提供支持，我看了一下，主要集中在涉及配置，缓存，反射等特有属性相关代码中，这个还算在预期之中，不过看到一堆的红叉叉还是一阵头疼，没办法，自己的类库，哭着也要码完，下边介绍下移植的步骤。

　　1. 添加项目文件

　　为了项目直观和方便管理，我将原来的OSS.Common类库修改名称为OSS.Common.NET45，新建一个OSS.Common的标准库项目，两个项目文件放在同一目录下，说明一下，vs2015如果要建标准库项目需要先建可移植类库，在类库属性页修改，如果不清楚请看上一篇文章介绍。

　　这个时候如果你直接生成OSS.Common.NET45的项目，是会出现报错的，哪怕你没有做任何实际的代码的操作，主要是因为添加可移植类库需要project.json的文件进行依赖管理，当他们在同一目录下时，nuget会把project.json中的依赖默认执行还原操作，虽然你当前是在生成OSS.Common.NET45项目，没办法，就是这么傻，如果你遇到了这个错误，在当前目录中再建一个对应当前项目文件的project.json文件就好了，这里我添加了OSS.Common.Net45.project.json文件，文件中添加如下代码：

{
"frameworks": {
"net45": {}
},
"runtimes": {
"win": {}
}
}

　　2. 代码集成

　　新建好对应的解决方案之后，把代码文件附件到新建的标准库下，这个时候直接生成会有很多错误，这个时候我们就需要祭出条件编译这个大招了，因为以后主要是维护标准库，所以我在旧NET45的旧项目上新建了NETFW的条件编译符号 ，剩下的就是一个个错误完善了。

　　在处理兼容的过程中，主要会面临这几个问题，1. 标准库完全不支持   2.  标准库和Framework的调用方法不一样， 3. 可以间接完成标准库的实现

　 这里我把我遇到的情况各举一个例子供大家参考：

　　1.  标准库完全不支持，这个最典型的就是缓存模块，在.net standard下，System.Runtime.Caching类库完全被移除了，没办法，只能使用#if NETFW 完全把Module模块下的默认Cache实现给屏蔽了，只能在Framework下才能使用默认实现（本来打算自己实现一个缓存类的，不过发现可能会带来不可预知bug，作废）。

　　2. 标准库和Framework的调用方法不一样，举个例子就是Type类型下的IsEnum属性，在net standard下需要.gettypeinfo().IsEnum才可以，举例代码：

#if NETFW
if (!enType.IsEnum)
#else
if (!enType.GetTypeInfo().IsEnum)
#endif

　　3. 可以间接完成标准库的实现，这常见的如 list的ConvertAll方法，在Framework下有默认实现的，标准库下是没有的，这里我在ConvertExtention类自己定义了个一个：

#if !NET40
public static List<TResult> ConvertAll<TPara, TResult>(this List<TPara> list, Func<TPara, TResult> func)
{
if (list == null)
return null;
var resultList = new List<TResult>(list.Count);
list.ForEach(e => resultList.Add(func(e)));
return resultList;
}
#endif

 当然还会有其他的一些问题，不过还好，基本都已经解决，如果有不清楚的可以去下载oss.common代码自行查看

　　四. nuget打包部署

　　这个相对简单，在两个解决方案中分别生成对应的dll，在lib文件夹中分别添加net45 和 netstandard1.4 文件夹添加对应的dll就行。

需要注意的一点就是，最好添加个各自的依赖，举个例子，标准库的Hmacsha1加密算法在“System.Security.Cryptography.Algorithms” dll程序集下，如果在调用项目中没有引用这个dll，生成是不会报错的，但是当代码执行调用的时候就会弹出程序集未找到的错误，当然如果发现这个问题也可以通过nuget线上安装命令（install-package）安装。

　　给大家看下我的nuget文件配置：