大約是上周五，在提交CYQ.Data V5.5.8.1版本到Nuget後，看著C盤還有7G發了一會呆。之後做了一個決定，卸載了VS2015，現在C盤有10個G。到了微軟官網，下載了社區版，把VS2017給裝上了， ...
閑話幾句：
自從上周開始，IOS人員逝去，就開始接手IOS的代碼了。
並開始整理IOS的代碼（包括當時一開始設計的開發框架）。
在未來不遠的日子里，設想是有一個系列詳細的介紹I戀App和IT連App及前後端所有涉及的技術系列。
同時還準備發佈一個IOS的開發框架，為十二星座再湊一個成員。
閑話結束，下麵看正文：
CYQ.Data 支持DotNet Coe 的折騰過程：
大約是上周五，在提交CYQ.Data V5.5.8.1版本到Nuget後，看著C盤還有7G發了一會呆。
之後做了一個決定，卸載了VS2015，現在C盤有10個G。
到了微軟官網，下載了社區版，把VS2017給裝上了，好在可以選組件，只挑.NET Core 相關的，5個多G就完事。
安裝好之後，建一個類庫工程，把整套源碼Copy過去，依賴項就是我們平時引用dll的地方：
開始編繹，並見證奇跡：一堆錯誤。
還好，VS2017在錯誤提示方面很人性化，分批給你顯示錯誤數，讓你解決一批再出來一批。
不像當初在VS2015折騰.NET Core 1.1的時候，一下子出來幾百個錯誤，梁靜如都救不了你。
面對錯誤：怎麼處理、支持Dotnet Core ?
折騰.NET Core 1.1的時候：
那時候是把CYQ.Data的源碼給重構整理了一次，把不支持的都單獨給抽離出來。
像這樣，比如那時候不支持序列化，就把涉及序列化的都抽出來放到一個文件：
通常一個類，會分拆出幾個partial的部分類（不支持的用於被排除）
想法挺好：
通過排除某些文件夾的方式，來達到切換的狀態，這樣可以不用維護兩份代碼。
但是：
要達到去掉文件夾還能編繹完整通過的解O方式，由於有些是強關係，關是業務整理，工作量大的出奇。
一些代碼還得修改為反射的動態調用，才能達到分離文件也正常，好不麻煩。
關鍵還是那時候的版本缺失的類庫太多，折騰沒幾天，放下了，回頭才是岸。
折騰.NET Core 2.0：
1：想過針對性的寫一個迷你版本。
但沒那麼簡單，要有激情，要有大量時間，這些條件要同時滿足不容易。
同時意味著又多一個要維護的框架，雖然我維護中的框架已數不過來，多一個也不算多。
可時間對於認真的人，總是不夠用啊！！！
2：通過增量方式，解決版本支持問題
上面說到，折騰 .NET Core 1.1 時，是想通過減量排除來解決問題，結果不得其門。
事情放一放，一回頭，解決問題的方式，就是來的那麼巧，那麼妙。
這回很理所當然的，就想到用增量的方式來解決問題。
CYQ.Data 如何通過增量代碼支持.NET Core
對於每一個提示不存在的類，VS環境中滑鼠放上去時，都會有一個提示重構，通過它可以減少不少工作量。
1：為每一個不支持的類、方法、或屬性，都用重構的方式，重新生成一個類文件，並用對應的名稱空間整理放好。
通過這種方式，整理出不支持有差異化的類庫，而且也可以清楚知道，框架里引用了哪些類是 .NET Core所沒有的。
然後先順利編繹通過。
2：重寫新建類庫的實現，比如，重寫讀配置文件：
using CYQ.Data;
using System.IO;
using CYQ.Data.Tool;
using System.Collections.Specialized;
namespace System.Configuration
{
internal class ConfigurationManager
{
static string appSettingJson = string.Empty;
static ConfigurationManager()
{
string filePath = AppConfig.WebRootPath + "appsettings.json";
if (System.IO.File.Exists(filePath))
{
appSettingJson = File.ReadAllText(filePath, Text.Encoding.UTF8);
if (!string.IsNullOrEmpty(appSettingJson))
{
appSettingJson = appSettingJson.Replace("\\\\", "\\");
}
}
}
private static NameValueCollection _AppSettings;
public static NameValueCollection AppSettings
{
get
{
if (_AppSettings == null && !string.IsNullOrEmpty(appSettingJson))
{
string settingValue = JsonHelper.GetValue(appSettingJson, "appsettings");
if (!string.IsNullOrEmpty(settingValue))
{
_AppSettings = JsonHelper.ToEntity<NameValueCollection>(settingValue);
}
}
if (_AppSettings == null)
{
return new NameValueCollection();
}
return _AppSettings;
}
}
private static ConnectionStringSettingsCollection _ConnectionStrings;
public static ConnectionStringSettingsCollection ConnectionStrings
{
get
{
if (_ConnectionStrings == null)
{
_ConnectionStrings = new ConnectionStringSettingsCollection();
if (!string.IsNullOrEmpty(appSettingJson))
{
string settingValue = JsonHelper.GetValue(appSettingJson, "connectionStrings");
if (!string.IsNullOrEmpty(settingValue))
{
NameValueCollection nv = JsonHelper.ToEntity<NameValueCollection>(settingValue);
if (nv != null && nv.Count > 0)
{
foreach (string key in nv.Keys)
{
ConnectionStringSettings cs = new ConnectionStringSettings();
cs.Name = key;
cs.ConnectionString = nv[key];
_ConnectionStrings.Add(cs);
}
}
}
}
}
return _ConnectionStrings;
}
}
}
}
配置文件和System.Web這兩個是經常用到的東西。
相對配置文件的讀取，System.Web的，麻煩了一些，需要Nuget上引用Microsoft.AspNetCore：
引用好後，再重寫裡面的內容，具體的內容，這裡就不貼代碼了，代碼可以見源碼處。
由於這周末兩天臨時集中處理，剛處理好，只做了簡單的MSSQL的測試。
所以來不及發佈Nuget上，先寫文了，等哪天測試穩定了再上Nuget。
CYQ.Data 支持.NET Core 的方法：
1：GitHub下載CYQ.Data的源碼（會發現多了一個文件夾）
地址：https://github.com/cyq1162/cyqdata
由於目前還沒提交解決方案文件可以直接運行項目，所以現在提前提前體驗的需要自己建類庫項目了：
2：自己新建一個類庫項目，取名叫CYQ.Data，把源碼都Copy過去（包括DotNetCore）
3：Nuget上引用Microsoft.AspNetCore。
編繹，然後就大功告成了，在你的.NET Core 項目里引用類庫項目就可以了。
如果涉及到Web，還需要有兩個註入的地方：
在MVC項目中調用app.UseStaticHttpContext()。
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
app.UseStaticHttpContext();
.....
}
在沒有註入 HttpContextAccessor的項目中，還需在ConfigureServices 方法中調用
services.AddHttpContextAccessor();
總結：
一個周末，一個巧合，一個連續的激情奮戰。
CYQ.Data 的.NET Core支持工作，就這樣告一段落了。
測試了MSSQL是基本通過，剩下的都好說了！！！
後面Taurus.MVC還是Aries，估計離支持.NET Core也不遠了。
不過，接下來，又要進入IT連創業的狀態了。
對於IT連，結合一些網友的建議，最近也有不少思考。
對接下來的產品優化及走向，又一波傷腦估計是在所難免。
另外，運營還缺的一篇文章，回頭也還得補上。
最後的最後，仍是感謝大伙的關註！！！
