.NET Standard v2.0.0 官方版

.NET Standard 2.0于今日发布，是一款专业的编程工具，可以帮助您进行轻松的查找和收集信息，快速建立一个程序，包括代码、文件、图片、网页、网址等。为了方便大家下载，小编为大家提供了详细的下载地址，需要的朋友可以下载！

软件特点

1. 基础用户系统设备信息实体定义

2. 主流加解密方案实现(md5,aes,sha1,hmacsha1)

3. 常规实体DTO转化，静态扩展方法(时间，字符串等等处理)

4. 基础日志，缓存，异步辅助静态类及默认方案实现(采用了简单Provider模式，使用者可以注册自己的实现方案)

5. 全局结果，分页实体定义。

软件功能

1、代码共享：

.NET Standard是API集合，更是代码实现标准，所有.NET实现必须符合该标准，防止代码碎片化。.NET Standard被设计用来作为替代可移植类库Portable Class Libraries(PCL)的构建工具。

2、API支持：

在.NET Standard 2.0中API支持数量增多，包含API数量为32000个，.NET Standard 1.6 中API数量为13000个，目前为止已经包含.NET Framework中的大部分APIs，这意味着可以轻松地将现有代码移植到.NET Standard，从而使现有代码支持基于.NET Standard实现的任何平台，参看平台支持列表。

3、.NET Framework兼容模式：

目前绝大多数的NuGet软件包使用.NET Framework，大多数项目被禁止引用到.NET Standard项目，因不是所有的项目依赖都支持.NET Standard，这是在.NET Standard 2.0中加入兼容模式的原因，使.NET Standard项目可以直接引用.NET Framework类库。目前70%的Nuget软件包是兼容.NET Standard 2.0，可能在某些特殊情况下不起会兼容失败，比如：WPF中的.NET Framework类库。

.NET Standard 2.0使用教程

一. 方案的选择

这个其实在上篇文章中已经做了介绍，当前.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 ConvertAll<tpara, tresult="">(this List list, Func<tpara, tresult=""> func)

{

if (list == null)

return null;

var resultList = new List(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文件配置：