V君的博客

自己动手用C#写无盘引导服务

作者：V君 发布于：2020-3-5 22:18 Thursday 分类：我的应用

发表一下最近折腾的东西，还没折腾完，因此不太TL;DR，再扯扯 (pia

[ 源代码 ] 目前只做了 DHCP、TFTP 和 iPXE 用的 HTTP 脚本服务。由于只是勉强能用，并不友好，因此尚未提供直接可用的二进制文件

— 使用方法：开始 —

将源代码弄下来，还原 NuGet 包，编译。导航到解决方案根目录的 bin 文件夹，我把它们的输出全都指向这里以方便编辑配置文件。

• 编辑 DHCP 配置文件，正确设置监听地址
• 编辑 TFTP 配置文件，正确设置监听地址、正确设置根路径
• 编辑 HTTP 配置文件，正确设置监听前缀

源代码和下面的描述已经差别很大，DHCP池已经实现，等什么时候蛋疼再回来扯扯（被打x

启动这三者，不要忘记调整防火墙，插好网线启动从机，设置好 BIOS 使其从 PXE 启动。这时候还不能顺利引导，DHCP 服务会在 DhcpEntries 文件夹会自动生成 MAC 地址的对应的 json 配置文件，修改 default 配置文件设置除了IP之外的字段，如子网掩码、网关、DNS、启动文件名，然后再在对应 MAC 的配置文件里面指定 IP 地址，将 Enable 字段置为 true。注意字段 Enable 对 Default 配置文件无效。这时候从机应该能分配到 IP 地址，然后去 TFTP 获取启动文件了。本例使用 iPXE 作为引导。

本例提供的 iPXE 嵌入了【再次获取 DHCP 并将启动文件名作为 chain 目标】，可以将 chain 指定为 HTTP 的 URI，从服务器吐出脚本来实现动态执行。通过 iPXE 发出的 DHCP 请求带有 UserClass 字段，会自动生成配置文件，可以另外指定启动文件名为 HTTP 网址。

配置文件的叠加顺序为：Default → Default-【UserClass】 → MAC → MAC-【UserClass】。值为 null 的字段将被忽略。接下来就可以去 IpxeScripts 文件夹配置 iPXE 脚本了。引导部分到此结束，接下来的步骤是连接到存储服务器、启动系统了。

— 使用方法：结束 —

— 扩充：开始 —

常见的的无盘使用 iSCSI 方式连接到服务器，详细用法请参考示例或查阅 iPXE 使用手册。iSCSI 服务端可以使用 StarWind 或者 TalAloni/iSCSIConsole 亦或者是 我的fork。 我在 TalAloni 的基础上增加了大容量、可加载 RamDisk 和类似 StarWind 的 ibv 支持。能从一个镜像中创建分支快照，能让多台机器同时使用，有点像 VMware 的链接克隆。

— 扩充：结束 —

— 扯扯：开始 —

刚刚开始的时候我用了 TFTPD32、Grub4Dos、固定脚本的 iPXE、还有 Star wind。由于效果很不理想，得想办法解决。 TFTPD32 的毛病：分配IP地址时间较长、TFTP经常抽筋；StarWind 的毛病：服务进程经常崩溃；尽管 TalAloni 的实现很稳定，但它的界面简直就是个 DEMO，每次打开都要配置……后来深入了解 DHCP 协议，发现可以它很简洁，可扩展性又强，再了解 iPXE 动态脚本，这套组合拳就打出来了。

虽然 DHCP 和 TFTP 的协议都挺好搞，但 iSCSI 协议就复杂了，想让指定的 Target 能根据客户端 iqn 自动创建快照， 实现不同机器连接到同一个 Target，却是各自使用自己的快照，目前还在咕咕咕（

— 扯扯：结束 —

标签: 软件开发 C# HTTP PXE DHCP TFTP iPXE

评论(7) 引用(0) 浏览(1778)

Xamarin Android 新手历险记之 AccessibilityService

作者：V君 发布于：2019-11-30 19:49 Saturday 分类：折腾手记

最近开始折腾 Android 的原生功能，想获取显示在屏幕上的界面元素。说到 Android 还想用我大 C♯ 去写，当然就是 Xamarin 啦！和往常一样，还是从 TL;DR 开始，然后再展开详细。

－ TL;DR －
1. 在项目中新增一个类，本例命名为 MyAccessibilityService
2. 使其继承于 AccessibilityService （Android.AccessibilityServices）
3. 追加必要的 Attribute ，如 Service、IntentFilter、MetaData
4. 重写 OnServiceConnected 方法增加 SetServiceInfo 调用
5. 重写 OnAccessibilityEvent 根据 ServiceInfo 做对应动作，达到目的

－ 展开 －
1. 略 (ｏ ‵-′)ノ”(ノ﹏<。)
2. 略 (ｏ ‵-′)ノ”(ノ﹏<。)
3. 这里可以稍稍展开
 ✸ Service 特性主要是 Label 和 Permission
  > 用 Label 来指定服务的显示名称
  > 用 Permission 指定必须的权限 BindAccessibilityService
 ✸ IntentFilter 喂进去一个 "android.accessibilityservice.AccessibilityService"
 ✸ MetaData 喂进去 "android.accessibilityservice" 和 Resource = XML 资源路径
  > XML 路径一般是 "@xml/accessibility_service_config"，在对应地方写好配置文件即可
  > 为了能访问界面元素，确保在配置文件中启用 android:canRetrieveWindowContent
  ⚠ 注意 MetaData 第一个参数写错不会有检查，只会让服务不按XML配置文件工作
4. 这里主要是创建一个 AccessibilityServiceInfo 实例，然后喂给 SetServiceInfo 方法
  > Flags 属性确保有 RetrieveInteractiveWindows 位
  > EventTypes 用来给接下来的地方做事件筛选，比如用 WindowsChanged
5. 到这里就可以开始搞事情啦
  > 使用当前对象的 RootInActiveWindow 属性获取界面元素的树状结构根节点

－ 再稍稍补充一下 －
如果只有 Service 而没有主界面，那就得手动跑到系统设置的辅助功能去启动服务。
有的国产Android手机系统界面被魔改得连辅助功能入口都被砍掉，这太尴尬。
我们可以在主界面做个按钮来导航到辅助功能设置：
1. 使用 Android.Provider.Settings.ActionAccessibilitySettings 实例化 Intent
2. 将其喂给 StartActivity 就可以实现捷径了

－ 感受 －
这次能分担给大家的东西并不多。
我不会说因为 MetaData 第一个参数写错，然而没有报错，也获取不到界面元素，让我花了很多时间才找到问题所在。这个细节上咕狗做得很不厚道呀……

说好的每月一篇文章，这次有点踩线呀，虽然创建时间是19点，但发布时已经超过零点了，咕咕咕

标签: 软件开发 C# Android

评论(0) 引用(0) 浏览(1314)

初体验.NET Core 3.0，Core新特性和传统Framework的差别

作者：V君 发布于：2019-9-30 17:21 Monday 分类：折腾手记

这次不是解决问题，因此不像往常那样有TL;DR，那就做个TOC吧

－ TOC －

1. 框架程序集(差别)
2. 接口默认实现(新特性)
3. 编辑并继续(差别，已更正)
4. 通过SSH远程调试(新特性)
5. 项目文件(差别)
6. 嵌入资源(差别)
7. ASP .NET Core(差别)

－ 0.先扯扯 －

最近更新了 VS2019，终于有机会接触 .NET Core 3.0，在看官方文档前先行体验一波，体验过程不断收集发现就有了本文的TOC，如果你去看文档，会发现有少量文档未提及的差别，也为撰写本文提供了动力。主要从个人体验总结。

－ 1.框架程序集(差别) －

从新建第一个Core项目开始，和传统Framework的差别就能体现出来，Core已经自动把整个系统类库的所有程序集作为SDK引用到项目中，不像从前需要手动引入各种系统类库程序集。

－ 2.接口默认实现(新特性) －

早在半年多以前就听说，C♯ 8.0 将能够在接口中定义包含方法体的方法，这个特性名为「接口默认实现」，也是打动我，使我投奔Core的诱惑之一。亲手操练之后发现，现在不仅能在接口中写实现方法，更能定义常量、甚至还能写静态方法，昔日的接口扩展方法将可以用默认实现代替。

－ 3.编辑并继续(差别，已更正) －

这个差异在16.3.0得到更正，现在已经能在改变当前语句的同时将代码变更应用。（请无视这一条）编辑并继续：在调试中命中断点停下来，编辑代码，改变当前语句并继续执行。这里有点细节和传统不一样，需要改变操作顺序，会稍稍造成一点体验差异。传统Framework调试时我们可以按照 命中断点→修改代码→拖动箭头或者使用上下文菜单来改变接下来要执行的语句，拖动在改变语句的同时，代码变更会生效，使我们能够执按修改如期执行；到了.NET Core就有点不一样了，修改完代码之后不能紧接就着改变当前语句，这会实代码变更的提交动作被跳过，执行的行为和看到的代码将会不一致，我们只能继续往前走一步才生效。操作顺序就变成 命中断点→改变当前语句到要修改的代码前→修改代码→继续执行。

－ 4.通过SSH远程调试(新特性) －

在过去要调试运行在Linux上的.NET应用程序，只能依靠第三方调试器，比如之前提到的MonoRemoteDebugger，第三方工具的体验和稳定性都远远比不上官方集成功能。现在我们可以通过SSH的方式直接附加到远程进程了。

－ 5.项目文件(差别) －

过去的C♯项目文件记录着所有已包含的文件，而且变更后VS会重新载入项目，动作有点大。在Core之后有了极大改善，项目文件不再一一记录包含文件而是引入默认行为，将项目目录下的文件以扩展名对应默认生成行为的方式默认包含到项目中，如果有变更则仅记录变更的项。在项目文件变更后也极大地减轻了重新载入（刷新、应用变更）项目的动作。

－ 6.嵌入资源(差别) －

这一点还没有查到相关文档。受影响的地方是生成操作为「嵌入的资源」的项，若和旁边的.cs文件同名（任意扩展名），则会生成与.cs文件中定义的第一个类全名的嵌入资源，且不带扩展名。若在.cs文件旁边有两个同名（不同扩展名）的文件设置为嵌入资源，将引发重名编译错误。这个行为和传统Framework不同。

－ 7.ASP .NET Core(差别) －

关于ASP.NET Core和传统ASP.NET的差别太多，这里就简单点一下个人感受。对于ASP.NET Core而言Web服务器不再是必备环境，引入了SelfHost的工作方式。HTTP Runtime格局也有巨大变化，传统ASP.NET想要以最简单粗暴地方式处理请求需要引入HTTP模块，到了ASP.NET Core，新建一个空项目就是一个空的回调并传入HTTP上下文给你处理，简单粗暴更上一层楼了！

差点以为这个月会打破惯例至少发表一篇文章…

标签: 软件开发 C#

评论(0) 引用(0) 浏览(995)

使用FluentMigrator和EntityFramework，实现相对可控的多库兼容CodeFirst体验

作者：V君 发布于：2019-8-31 15:49 Saturday 分类：折腾手记

－ TL;DR －

1) 在 NuGet 找到并安装 FluentMigrator、EntityFramework、数据库提供程序、Dapper
2) 确认 App.config 配置、增加连接字符串并明确 providerName
3) 应用程序初始化时按需配置环境
4) 配置 MigrationRunner
5) 撰写、调试数据库初始化 Migration
6) 使用 EntityFramework 操作 FluentMigrator 创建的数据库，Enjoy it！

－ 扯扯 －

我在之前的文章中提到过，EntityFramework的纯CodeFirst方式并不好吃，因此一直以“基于现有数据库的CodeFirst”方式使用EntityFramework，即先手动创建数据库，再对应数据库结构手打实体模型。这种方式需要将创建数据库的SQL脚本保存下来，以便反复部署。如果要兼容不同数据库还需要为它们分别保存SQL脚本。在数据库有变更时还得反复更新脚本，这太麻烦了。

直到最近折腾的一个 ToyProject 想要分别适配 MySQL 和 SQLite 才重新考虑这个问题，然后做了尝试，尽管总体来说并没有很优雅，也总比EF的纯CodeFirst要靠谱得多。接下来是细节展开，如果光是看TL;DR觉得一脸懵逼，应该能有所缓解。

－ 展开 －

1) 实际安装的NuGet包分别是
✸ FluentMigrator.Runner ： 这个包之后有一大堆依赖被自动追加，不要被DLL数量吓到唷
✸ Dapper ： 在初始化MySQL时需要用到
✸ System.Data.SQLite ： 已包含EF提供程序的依赖
✸ MySql.Data.Entity ： 不解释
2) 确认 App.config 中的提供程序、配置连接字符串
✸ 安装最后两个包之后，App.config 会在以下两处自动增加提供程序
  > configuration/entityFramework/providers
  > configuration/system.data/DbProviderFactories
  ⚠ NuGet包自动加上的提供程序配置可能会有问题，咕狗爆栈可以找到解决方案
✸ 连接字符串 ：configuration/connectionStrings/add 用起 providerName 与提供程序对应
3) 应用程序初始化
✸ DataDirectory ：针对 SQLite 在当前 AppDomain 上设置配置数据文件路径
4) 配置 MigrationRunner
✸ 创建数据库 ： MySQL在连接字符串中指定了数据库名称，但实际不存在的时候会炸
  > 实例化 MySqlConnectionStringBuilder 获取并剔除连接字符串中的数据库名称
  > 用未指定数据库的连接字符串打开连接，检测到数据库不存在则创建(用Dapper偷懒)
  ⚠ 对于 SQLite 仅需简单打开数据库连接就能创建数据库文件
✸ 根据连接字符串的 providerName 配置不同数据库提供程序，可以参考文档示例
5) 写 Migration
✸ 一般情况下只需要在 Migration 中无脑 Create 各种需要的表和索引就可以了
  > 让我们来看看二般情 ： 况针对 MySQL 使用 Execute.Sql 设置字符编码
6) 使用 EntityFramework，到这里就没太多可以扯的东西了
✸ 比起把连接字符串或其名称喂给 DbContext 我更喜欢直接给 DbConnection 实例

－ EOF －

这就是本月的主要内容吗？从信息量上来说有点牵强呀…

标签: 软件开发 C# 数据库 ORM

评论(0) 引用(0) 浏览(1120)

用C#实现用户自定义公式计算

作者：V君 发布于：2019-7-13 13:33 Saturday 分类：挖坑经验

这次主要是讨论各种已知的实现方式，然后扯扯目前的实现，并非着急解决问题

因此没有TL;DR (pia 如果你着急，可以先看看我目前选择的实现方式，已经托管在公开的GOGS了。

按用户定义的计算公式做各种数据操作，在业务系统中并不罕见。最近就遇到了这样的需求，新项目，可以比较宽松地选择实现方式。（我不会说现有老项目也有公式计算，使用基于SQL的实现方式，相当的恶心）

说到公式计算其实就是动态行为嘛！

我首先想到的就是将用户输入处理成Linq表达式文本（如关键字、字段名称替换），然后再喂给动态Linq表达式解析解析器，最后编译成委托去执行。经过实践发现这种方式存在许多限制，不合适用在太开放的用户自定义公式的场景。停止进一步尝试，表达式解析引擎不是那么容易魔改的，投入咕狗的怀抱寻找更合实现方法。

咕狗一圈回来一共找到了5种方式，分别是：

• SQL（和老项目的方式一样，相当恶心）
• DataTable的Compute方法（同样恶心）
• JScript:Eval（运行效率？弱类型脚本语言并不好吃）
• 造（找）轮子（后序式计算或其他自行实现，如ToolGood.Algorithm）
• 代码编译执行（需要考虑资源释放，也就是要创建独立的AppDomain并在用完之后卸载掉）

（用动态Linq方式居然一个人也没有？编译出来的委托还带自动垃圾回收释放内存呢！）

造轮子是不可能造轮子的光是表达式解析就是个课题了，用别人做好的东西又担心有风险，主要是在PM的要求下别人的东西好不好修改这方面。那就只剩下凑代码编译来执行了。

扯一扯目前的做法吧，还是分成几个步骤来实现：

1. 中文标识符映射
2. 提前浮点类型转换
3. 编译代码
4. 调用已编译的代码
5. 释放资源（TODO）

为了使用户体验更友好，字段名、部分函数名、操作符之类的玩意儿，允许用户以中文代替。那么第一步就是将这些中文标识符提取出来，替换成可编译的代码标识符。最初的实现方式是粗暴地按空格分割表达式项，逐个检索字典替换。后来发现这样做太糟糕，总不能让用户把操作数和运算符都用空格分开吧？老早就知道动态Linq表达式解析器里面有解析表达式项地实现了，试着扒一扒。弄出一个专门提取表达式项的玩意儿，除了不支持字符转义和全角符号，其他方面还凑合吧。连续两个中文标识符肯定是要用户自己以空格分开，现在第一个步骤已经相对完善。

尽管以代码编译的方式解决了动态Linq表达式不支持的持隐式转换，但C#中的浮点类型们似乎还是有些水火不容。他们是decimal和double、float，我们需要根据使用场景来决定兼容的转换方向，比如计算金额的时候，应该提前将double和float转换成decimal；再比如要计算参数的时候先将decimal转成double，再去计算，以避免编译失败。（虽然不知道有没有用decimal保存参数的场景，先提前做好准备吧）

编译代码就简单得多了，只要确定委托签名，就凑出只有一个静态方法的类的可编译代码。将凑好的代码喂给CSharpCodeProvider的CompileAssemblyFromSource，稍微看看编译结果有没有问题，就能通过反射取得编译后的方法，把它作为委托放到字段里；如果发现有编译错误，那就将错误信息整合到异常消息丢出去。

调用代码这一步没什么好扯的了，已经将表达式编译成明确的委托，只需要将参数怼进去，结果就会返回来。如果还不清楚，那就看看我做的PoC界面实现吧！

最后一个步骤就稍稍有些麻烦了，说是要改变整个格局都不为过。打算集成到具体项目再考虑，并没有包括本文提供的Poc中，现在只能干巴巴地扯一下。参考上面提到的链接，在.NET域之间穿梭是一个相当麻烦的事情，他的工作机制决定了能传输的形式——要求可序列化，且域之间的对象是不能直接引用的，要通过代理对象去操作，其参数似乎也要求可序列化，这样就很大条了。就算能很好地控制出入参数，在大量计算地时候还是有不小的序列化开销。我的方案是把操作颗粒度划得更大一些，整个计算操作在域里面进行，包括数据源的获取，这样就减少了绝大部分跨域操作，甚至还有敦促垃圾回收的作用。那么问题来了，是将计算结果跨域传回来呢？还是在域里面就包括输出的动作？这就要视具体情况来确定了…

那么，每月至少刷一次的存在感就扯到这里，我们下个月再见（pia

标签: 软件开发 C# 动态编译

评论(2) 引用(0) 浏览(1593)