上篇（.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文件配置：
如有其它疑問，歡迎關注公衆號（osscoder）：
