Net standard扩展支持实例分享
2017-10-13

这篇文章就是讲解我的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文件配置:


原文地址: http://www.cnblogs.com/sunhoy/p/6380478.html