V君的博客

牛刀小试 Roslyn 之简易 Mapper 生成

作者：V君 发布于：2023-7-12 18:56 Wednesday 分类：挖坑经验

TL;DR [ 下载 ] [ 源代码 ]

用法：
 1. 下载 CodingCannon.7z.001 和 002 放在一起解压，运行 CodingCannon.exe
 F. 将要生成 mapper 的代码文件拖入窗口中，若代码文件有效，就会像下图那样得到代码

故事时间

最近在给现有项目做扩容升级，后台服务全都换最新的 .NET 6.0 LTS ，但 Web 还停留在经典 framework 甚至没有前后端分离 :( ，尽管接下来要重建它，但不得不适配到新的中间件，新的模型实现，出现了许多需要映射 dto 的地方，由于想要编译时检查而不再使用 AutoMapper （Auto Mapper 不能很好的检查属性引用，容易写漏写错），那就写几行代码来生成“硬编码”Mapper。和过去的用正则提取标识符不同的是这次用上了 Roslyn 编译器中的 CodeAnalysis.CSharp 来实现代码解析，这样就不用纠结代属性定义有没有换行之类的低级问题。

废话时间

失踪人口出现了 \\(^∇^*)， 这段时间在出差体验现场工作的 996 生活。 看来只要出现缺口就会整个坏掉， 之前的每个月刷一次存在感的原则就坏掉了， 从中招开始 _(:з)∠)_

标签: 软件开发 C# 编译原理

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

使用 Web API 下载 PDF 遇到的坑

作者：V君 发布于：2022-4-28 20:13 Thursday 分类：挖坑经验

TL;DR：

• 将 XHR 的 responseType 设置为 "arraybuffer"
• 如果使用 axios 则要在参数对象加 responseType:'arraybuffer'
• 获取响应之后用 response 创建 Blob 然后交给 ObjectURL（别忘记type）
• 将创建好的 ObjectURL 交给 IFrame 直接呈现，或者交给 A 标签实现下载

听我扯扯：

前后端分离的项目中遇到需要预览（下载）PDF 的需求，而且用了基于请求头而非 Cookie 的验证方式，因此无法走 IFrame 直接把 API 的 URL 送进去。绕了一圈远路尝试解决验证问题，无果。

回过头想起可以让 XHR 下二进制数据的做法，咕狗“XHR PDF”找到爆栈上面的《XMLHttpRequest to open PDF in browser》。（其实这时候已经看到有回答在 XHR 指定 type 为 'arraybuffer' 了）然鹅把 BLOB 链接放进 IFrame 之后，文字和图片全都不见了，只剩下几页空白页（页数正确）。已经确认过后端输出的 PDF 正常，而通过 A 标签的 HRef 放入 BLOB 连接下载的文件大小跟服务器响应的不一样，体积大约翻了一倍。

在浏览器调试脚本发现 XHR 的 reponse 是字符串，在控制台用 typeof 确认过眼神，这时候只能去咕狗了，“xhr binary data”，第一条返回 MDN 上的《发送和接收二进制数据 - Web API 接口参考》，里面提到了 XHR 的 responseType 属性，设置成 "arraybuffer" 才能避免浏览器把输出内容错误地当成文本来解析。

至此问题完美解决，可喜可贺！这个月差点找不到值得发表的内容 _(:з)∠)_

标签: javascript Web技术 前端工程

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

用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) 浏览(1529)

搭建自己的NuGet托管服务器,并通过符号源服务器提供带源码的调试体验

作者：V君 发布于：2018-9-19 19:43 Wednesday 分类：挖坑经验

尽管花了不少时间但都是些坑或者自己没注意,这次不想扯,直接TLDR:

使用命令行把项目打包并推送到服务器 (参考官方文档)

1) 下载最新版NuGet.exe,

2) 为项目编写nuspec文件,可以通过spec参数创建一个模板

3) 分别使用pack命令打包库或pack -symbol也生成符号包

4) 使用push命令将这俩分别推送到对应服务器

+) 如果想连同PDB文件一起打包(可以堆栈跟踪里获得源代码位置),可以添加下配置到nuspec根

  <files>
    <file src="bin\$configuration$\$id$.pdb" target="lib\netxxx\" />
  </files>

 这样做有个副作用会让符号包生成时产生警告PDB文件重复

 还有一个副作用会让符号源失效,在DLL旁边PDB似乎挡住了前往符号源服务器的去路,

 导致F11进不去,你得在启动调试之前自己把输出目录的PDB删除

 目前的做法是写成生成事件,仅匹配Debug生成时删除指定的PDB文件

搭建NuGet服务器 (参考自官方文档)

1) 新建空白Web项目,引入NuGet包[NuGet.Server]

2) 修改web.config配置ApiKey或干脆禁用验证

3) 部署到服务器

搭建符号服务器 (参考X.D.的博客文章)

1) 创建空白MVC项目,引入NuGet包[SymbolSource.Server.Basic]

2) 在服务器上安装Windows Kits Debuggers,下载SDK安装器进行可选安装

3) 部署到服务器,配置好web.config指向上者安装路径的srcsrv

4) 如果用了主机头绑定和HOSTS,在服务器也需要配置指向自己的HOSTS

x) 这货好像也能当NuGet包托管服务器?（但貌似不能设置ApiKey验证

在VS使用自己部署的NuGet包服务器

1) 在菜单工具-选项打开选项对话框

2) 在左边选择NuGet包管理器-程序包源,添加服务器地址到列表,确定

3) 在包管理器检索时不要忘记切换到自己的服务器,或简单选择全部

在VS使用调试符号 (参考符号源官网文档)

1) 在菜单工具-选项打开选项对话框

2) 在左边选择调试-符号,添加服务器地址到列表

3) 接着在左边找到兄弟节点常规对里面的选项做一些改动,见参考文档

4) 在调试时对着提供了符号包的NuGet程序集调用按下F11, VS会自动找到源代码并进入调试

扩充话题

在程序集里嵌入Git提交哈希,可以使用[MSbuildGitHash]这个包来轻松完成

但这货有个缺点,如果机器上没安装Git或者当前项目不是Git托管,就会编译失败

需要自己指定MSBuild条件来绕过.

标签: 软件开发 源码管理 调试技术 .NET

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

WebActivatorEx重复执行?不!那是作为使用者的我们傻逼!!

作者：V君 发布于：2018-6-15 22:42 Friday 分类：挖坑经验

TL;DR:

如果在发布新版本后出现疑似WebActivatorEx启动入口被执行多次的情况

首先检查bin里面是否有上个版本残留的DLL，干掉它们就解决了，然后把锅甩给运维。

 

那么，开始我的故事。

～前奏～

由于首次在正式项目引入git源代码管理体系，仓库结构设计的相当散乱。

这不赶上重组git仓库，重新建立了解决方案，命名空间和项目名称也重新规划了。

～嘣咧挫～

好不容易发布一个新版本到测试环境，运行起来出现致命错误的黄页。

连最开始的初始化都没完成，错误处理也措手不及，好久不见的黄页就这样呈现出来。

～扯一扯～¶

由于不喜欢Log4Net这种只能用配置文件的充满Java味道的东西。

现在项目中的日志组件是由我自己实现的，有以下特性：

• 由写入时间决定文件名
• 6个级别，外加可选启用的虚拟级别“ALL”将其他级别内容凑一起输出
• 按指定大小分文件
• 多次启停可续写
• 自动删除指定天数的旧文件

写入方式是基于线程安全的FileStream共享只读打开，方便边写边看。

内容格式是三行一空行的条目：

• 第一行写时间、级别、线程信息（如果有写程序集，也能快速发现这次的问题。之后补上吧）
• 第二行写摘要，由开使用者定义的简短摘要
• 第三行写详情的JSON，有日志位置堆栈，可以加入任意对象作为附加信息

在日志组件初始化之后，我通常会打一句“Logger Init”在日志中体现应用程序启动。

我们有为此专门做了个小工具来分析日志，用上了Chris Nielsen的JSON可视化界面实现。

～诊断～

打住，话题收回来，黄页的错误信息是“文件被占用”，堆栈显示正在打“Logger Init”时…

一开始的时候很有自信，以为自己写的实现没问题，可能被文件共享出来占用了。

用Procexp查文件句柄,一个都没查出… 

但作为应用程序启动的体现“Logger Init”却被打进日志文件里…

老大的意思是想让我先把多节点负载均衡砍掉，以单节点跑起来，降低复杂度再诊断。

当时没辙只好听话照办喽，然并卯。

还是掏出诊断大杀器ProcMon看看“是谁动了我的奶酪”，看到结果时开始觉得自信不足了：

——真的是ASP.NET程序池进程访问的文件，而且是同一条原生线程访问了两次。

——第一次成功打开，第二次打开失败，最后还把文件关闭了——由CLR，程序都崩溃了嘛！

难道是自己的实现有问题，多线程竞态现象？

.NET的托管线程可能会复用原生线程，出现TID一样的情况也不能排除多线程。

在初始化的地方加了锁，然而问题依旧存在。其实并不是我的代码写的不严谨，这是后话。

咋办？

让文件打开的共享模式可读可写吧，想到了这样高风险的激进尝试。

然而——还是失败了，但仔细观察发现ProcMon监视条目详情有蹊跷：

第一次打开文件的共享模式是只读，第二次才是符合激进尝试的可读可写。

两次打开文件的原生堆栈有差异，很可惜看不到托管堆栈，如果能看到程序集就能解决问题了。

远程调试吧。没办法的办法了，在日志初始化的地方打个断点看看会不会两次命中。

调试结果令人十分失望，只命中了一次，打开失败的第二次。天知道第一次在哪儿打开？

这时猫同事建议我把“Logger Init”改一下，看看有没有打出来。这才恍然大悟。

我拒绝了建议，且断言上个版本残留程序集，去服务器bin看看，断言成立！

抓住运维的肩膀使劲晃，“你让我浪费了两天的时间排查”　乂目

～结语～

甩完锅之后还是要总结一下教训的，发布版本应该将之前的文件干掉，再把新的包部署上去。

标签: 软件开发 C# ASP.NET 软件故障诊断

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