自从上周开始，IOS人员逝去，就开始接手IOS的代码了。
并开始整理IOS的代码（包括当时一开始设计的开发框架）。
在未来不远的日子里，设想是有一个系列详细的介绍I恋App和IT连App及前后端所有涉及的技术系列。
同时还准备发布一个IOS的开发框架，为十二星座再凑一个成员。
闲话结束，下面看正文：
大约是上周五，在提交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的时候，一下子出来几百个错误，梁静如都救不了你。
那时候是把CYQ.Data的源码给重构整理了一次，把不支持的都单独给抽离出来。
像这样，比如那时候不支持序列化，就把涉及序列化的都抽出来放到一个文件：
通常一个类，会分拆出几个partial的部分类（不支持的用于被排除）
想法挺好：
通过排除某些文件夹的方式，来达到切换的状态，这样可以不用维护两份代码。
但是：
要达到去掉文件夹还能编绎完整通过的解O方式，由于有些是强关系，关是业务整理，工作量大的出奇。
一些代码还得修改为反射的动态调用，才能达到分离文件也正常，好不麻烦。
关键还是那时候的版本缺失的类库太多，折腾没几天，放下了，回头才是岸。
1：想过针对性的写一个迷你版本。
但没那么简单，要有激情，要有大量时间，这些条件要同时满足不容易。
同时意味着又多一个要维护的框架，虽然我维护中的框架已数不过来，多一个也不算多。
可时间对于认真的人，总是不够用啊！！！
2：通过增量方式，解决版本支持问题
上面说到，折腾 .NET Core 1.1 时，是想通过减量排除来解决问题，结果不得其门。
事情放一放，一回头，解决问题的方式，就是来的那么巧，那么妙。
这回很理所当然的，就想到用增量的方式来解决问题。
对于每一个提示不存在的类，VS环境中鼠标放上去时，都会有一个提示重构，通过它可以减少不少工作量。
1：为每一个不支持的类、方法、或属性，都用重构的方式，重新生成一个类文件，并用对应的名称空间整理放好。
通过这种方式，整理出不支持有差异化的类库，而且也可以清楚知道，框架里引用了哪些类是 .NET Core所没有的。
然后先顺利编绎通过。
2：重写新建类库的实现，比如，重写读配置文件：
class="brush:csharp;collapse:true;;gutter:false;">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。
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连，结合一些网友的建议，最近也有不少思考。
对接下来的产品优化及走向，又一波伤脑估计是在所难免。
另外，运营还缺的一篇文章，回头也还得补上。
最后的最后，仍是感谢大伙的关注！！！
相关文章
