活久见:表达式树编译执行引发VerificationException—操作可能会破坏运行时稳定性
作者:V君 发布于:2018-2-7 0:04 Wednesday 分类:挖坑经验
TL;DR:
当在使用表达式树编译成员绑定表达式,且存在隐式值类型装箱,
将表达式树编译成的委托执行起来的时候将会引发异常VerificationException,
并提示消息“操作可能会破坏运行时稳定性”。
解决方法为显式装箱之后再绑定,可能是表达式树在编译成IL时没有对其进行必要的校验。
至于是不是性能考虑就不晓得了。从结果上来看,似乎却在运行时(亦或者JIT时)有检查。
听我扯扯:
在项目中需要比较两个同类型对象实例,且将差异收集起来。
于是咱首先就想到:不要一遍遍写繁琐的判断!
而是使用动态行为——堆IL、拼代码动态编译或表达式树编译。
咱选择后者,比起堆IL和拼代码还是表达式树写起来更舒服。
就算使用动态行为,基础的动作还是由简单的逻辑语句组成。
首先要遍历要diff的类的全部属性,然后将两个实例对应的属性值读出来比较,
若值相等则忽略,若值差异则连同属性名和两个差异的值收集起来。
思路想清楚了就开始吧。
定义一个有3个属性的类,分别存放属性名,和两个值,作为差异条目模型。
命名DiffEntry,属性名是字符串,另外两个是object。
接着定义一个静态泛型类,静态构造里面构建每个属性的比较表达式树并将它们编译成委托,
公开静态方法Diff,返回DiffEntry的数组,调用编译好的委托。
命名ObjDiffCollector,存在引发装箱异常问题。
在gist描述为修订2,因为最初使用数组存放编译出来的委托,发生异常之后,
为了调查异常引发原因缩小范围,改为字典,键是属性名,值是委托,仅用在调试查看。
将问题缩小到值类型在DiffEntity的构造初始化成员绑定之后,
.↑字符串类型没有问题
开始一小会儿的懵逼,放狗出去并没有找到什么卵线索。
这段可以忽略
先贴上异常名称,咕狗很贴心地提示了“operation could destabilize the runtime”,
接着出来的只有一个爆栈帖子,提到使用一个第三方数据访问层引发这样的错误。
打住吧,换成中文消息搜一下看看。
和预料的一样然并卵,被一篇转载到成为互联网垃圾程度的文章刷屏。
文章清一色的提到使用redgate的性能测量库所引发。
到这里线索断了。时间也不早,还要赴约,就把问题撂下跑了。
离开电脑面前不久之后,又玩了一次当局者迷play。
在外头晃悠时忽然灵光一现想到可能是隐式装箱导致,最终证实这个想法。
THE MEAT AND POTATOES 圈重点啦
可能堆IL和表达式编译一样,没有经过太完整的代码转换过程,隐式行为需要显式表达。
这时候需要将绑定的表达式加一层,转换成object,也就是显式装箱。
最终得出可用的ObjDiffCollector。
回过头来想一想,发现CLR报这个错误也不无道理。
试想一下:一个非引用类型的结构体被装箱的情形,如果再复杂一点如果和原生代码扯上关系。
可能会导致意外的值复制行为,从而影响到整个应用程序的稳定性。
想当年,玩DllImport时,一不小心就内存损坏或者堆栈不平衡……
到此为止啦,收工!
接下来该考虑如何一步到位了,或许可以在一个表达式里面作完所有属性的比较和收集差异。
让代码的逼格显得更高。 乂目
标签: 软件开发 C# 调试技术 JIT LINQ 运行时错误
[不理想]使用EntityFramework6 Code First操作SQLite[Update1]
作者:V君 发布于:2016-9-15 20:22 Thursday 分类:折腾手记
这段时间一直在用EF6CF+MySQL忙得没完没了.终于到了假期,试试SQLite和EFCF看看手感如何吧!
新建项目开始折腾吧,从nuget上获取程序包,System.Data.SQLite 1.0.103
然后就是一坨自动依赖 Core/EF6/Linq, 删除EntityFramework.SqlServer引用
删除App.config,咱用SQLite就是想做个便携本地应用, 当然尽可能的在代码中配置
创建数据库上下文类, 继承DbContext
然后是类似MySqlEfConfiguration一样打一个特性上去, 发现并没有自带.
从爆栈上面找到个看起来靠谱的写法.结合问题和答案加到项目中.
然后就是添加迁移配置来创建数据库了, 就算不能自动变更也要来个初始化迁移来建库.
在程序包管理器控制台选择对应项目, 键入 Enable-Migrations 回车.
经过几次自动发起的生成, 尽管有报错, Migrations 文件夹和配置类出来就可以了.
接着还是像使用MySQL一样配置代码生成器, 在迁移配置类构造中追加配置
SetSqlGenerator , 这时发现生成器也没有自带, 网上还有很多说不支持
不过还是在爆栈找到了生成器的实现. 使用答案中的类实例作为生成器.
刚下下来的代码是编译不能的, 根据Resharper提示更换了命名空间才能用.
在数据库上下文类新增无参构造,给base传递Sqlite连接实例,
第二个参数true表示上下文拥有连接实例,可以自动释放.
走一下新增初始建库迁移吧! 在程序包管理器控制台输入 Add-Migration Init 回车!
用来创建数据库的初始迁移就出来啦! 尽管Up/Down方法体内什么都没有!
有了迁移, 那么生成一下SQL看看, 仍然是包管理器控制台, 键入 Update-Database -Script
又是几次自动发起的生成, 然后一个空的sql文件冒了出来... 哈哈 当然, 咱么还没加表呢!
赶紧加表看看效果吧! 回到数据库上下文类增加公开可读写属性IDbSet<T> T是你的实体类.
删除Migrations里的*******_Init.cs, 删除已有的数据库文件
以后要改变数据库都要删除它们再重新Add-Migration,
并且只能有第一次, 因为目前Sqlite的EntityFramework似乎还不支持自动迁移...
这也就是给文章标题打上[不理想]标签的原因.
这次的迁移Up/Down方法体里面有东西了, 分别是创建和删除表.
生成的sql文件crate table语句也出来了.
理所当然的发现没有迁移历史表 __MigrationHistory 的创建语句.
接下来是直接创建数据库, 包控制台里面输入 Update-Database 去掉后面的 -Script 参数
这时应该会在exe旁边冒出连接字符串中指定的文件名啊? 怎么什么都没有?
用Everything搜索文件名才发现, 原来这货跑到系统目录去生成了, 我去 _(:з」∠)_
于是接着咕狗,然后爆栈解决问题, 通过应用域里面类似环境变量一样的方式指定路径.
终于在指定位置自动创建了数据库, 对于每次结构变更只能重建数据库... 凑合着用吧.
Update1:
不同表名相同字段并且是外键时会创建同名索引导致SQL执行错误
需要在 MigrationSqLiteGenerator 以下方法做修改来解决
Generate(CreateIndexOperation)
Generate(DropIndexOperation)
将索引名称后缀上表名就可以了,
ltextWriter.Write(opeCriacaoIndex.Name + "_" + RemoveDBO(opeCriacaoIndex.Table));
ltextWriter.Write(opeDropIndex.Name + "_" + RemoveDBO(opeDropIndex.Table));
尽管Drop操作现在也没机会用得到, 先也修改吧, 哪天迁移功能受支持就可以直接用了.
应避免的 LINQ to SQL 聚合投影空值错误
作者:V君 发布于:2016-7-15 11:06 Friday 分类:挖坑经验
根本原因: SQL 在进行 SUM 这类聚合查询时如果一条数据也没有, 会得到 NULL.
如果你的投影结果字段用了不可空类型, 将会引发错误: null 无法赋值到不可空类型.
解决方法: 将聚合投影字段转换成可空, 并将聚合结果做空处理, 一般把空转成0.
可能出错的写法:
var result = DataBase.Table.Sum(p=>p.Amount);
修改以避免错误:
var result = DataBase.Table.Sum(p=>(decimal?)p.Amount)) ?? 0;
重新认识EntityFramework, 比较几个LINQ数据访问/ORM库
作者:V君 发布于:2016-5-27 9:29 Friday 分类:挖坑经验
前些年我曾说过 Entity Framework 就是个坑
但自从最近试着摆弄 ASP.NET Boilerplate Project 对Entity Framework大有改观.
原来版本6之后的Entity Framework完全可以把dbml dbLinq linq2db sqlite-net远远甩在后头.
dbml - LINQ to SQL 类
◆能从数据库生成设计器代码, 也能先设计再生成数据库
◆完整的复杂查询/投影支持
◇仅限MsSQL
dbLinq - 上者的一个类似克隆一样的实现 GitHub
◆支持多种数据库
○能从数据库生成设计器代码, 不支持自动创建数据库
◇复杂查询/投影不完善
linq2db - 近些年发起的开源LINQ数据访问/ORM库, 看起来是上者的重新实现 GitHub
◆支持多种数据库
◆完整的复杂查询/投影支持
◆能从实体类生成数据库, 也能从数据库生成实体类(T4)
sqlite-net - 轻量级sqlite数据访问实现, 因为轻量所以没太多功能 GitHub
◆单个源码文件加到项目即可使用
◆跨平台直接调用原生实现, 不依赖ADO.NET
○简单的LINQ支持
◇不支持复杂查询/投影
Entity Framework 6+ - 着看怎么完爆上面这堆
◆上述除了轻量级之外的所有优点
◆多种开始方式: CodeFirst,DbFirst,ModelFirst. (不过 CodeFist 就够了)
◆支持迁移,能按你对模型类的变更生成数据库更新脚本
◇目前尚未发现有缺点
◇使用一段时间后总算是找到了些缺点(?),可能是考虑到兼容不同数据库
LINQ表达式解析依赖于提供程序实现,
比如MySQL提供程序实现的表达式解析器的解析和投影就BUG满满,
具体表现为各种操作符报不支持或者导航属性投影字段混淆.
总之赶紧来用这货吧 ゚∀゚)σ
偷偷更新:其实EF的迁移并不太好使,还是基于现有数据库的CodeFirst跟Dapper混搭好 乂目
让mono也能用DynamicExpression::ParseLambda
作者:V君 发布于:2014-7-22 13:29 Tuesday 分类:折腾手记
网上一直传的反射 System.Web.Extensions 的私有类
System.Web.Query.Dynamic.DynamicExpression
中的 ParseLambda 方法来实现动态lambda表达式
Assembly asm = typeof(UpdatePanel).Assembly;
Type dynamicExpressionType =
asm.GetType("System.Web.Query.Dynamic.DynamicExpression");
MethodInfo parseLambdaMethod = dynamicExpressionType
.GetMethods(BindingFlags.Public | BindingFlags.Static)
.Where(m => (m.Name == "ParseLambda")
&& (m.GetParameters().Length == 2))
.Single()
.MakeGenericMethod(typeof(T), typeof(Boolean));
var func = (Func<string, object[], Expression<Func<T, bool>>>)
Delegate.CreateDelegate(
typeof(Func<string, object[], Expression<Func<T, bool>>>)
, parseLambdaMethod
);
在Windows底下一直好好的发挥作用
不过最近在mono跑了爆空指针, 或许是类名不同或者压根就没实现吧
不管了, 试着扒出M¥类库的代码看看能不能用吧.
过程略. (反编译,修正编译器生成标识符,切断依赖) 还挺顺利的 乂D
拿去用吧: System.Web.Query.Dynamic.cs.zip 尽管还整理的不够到位
(错误提示口胡和编译经过) 乂D
好吧, 原来dbLinq项目里也有 这玩意 , 用它吧, 这较靠谱
这个月0博文消灭乂D
blogger
Google Web Translator
热门日志
随机日志
最新日志
最新评论
- V君
@Quartz:(出现)... - Quartz
怎么不见人了呢... - V君
@Soar:DHCP 协议相... - V君
@Soar:当然是非... - Soar
@V君:谢谢 有空... - Soar
搞一个 1230v3+B85... - V君
@Soar:另外,也可... - V君
@Soar:iscsi服务端... - Soar
难怪这么卡,尤其... - Soar
clone了源码,提示...
分类
存档
- 2024年5月(1)
- 2023年7月(1)
- 2023年5月(1)
- 2022年11月(1)
- 2022年10月(1)
- 2022年9月(1)
- 2022年8月(1)
- 2022年7月(1)
- 2022年6月(1)
- 2022年5月(2)
- 2022年4月(1)
- 2022年3月(1)
- 2022年2月(1)
- 2022年1月(1)
- 2021年12月(1)
- 2021年11月(1)
- 2021年10月(1)
- 2021年9月(1)
- 2021年8月(1)
- 2021年7月(1)
- 2021年6月(1)
- 2021年5月(1)
- 2021年4月(1)
- 2021年3月(1)
- 2021年2月(1)
- 2021年1月(1)
- 2020年12月(1)
- 2020年11月(1)
- 2020年10月(2)
- 2020年9月(1)
- 2020年8月(1)
- 2020年7月(1)
- 2020年6月(1)
- 2020年5月(1)
- 2020年4月(2)
- 2020年3月(3)
- 2020年2月(1)
- 2020年1月(1)
- 2019年12月(1)
- 2019年11月(1)
- 2019年10月(1)
- 2019年9月(1)
- 2019年8月(2)
- 2019年7月(1)
- 2019年6月(1)
- 2019年5月(1)
- 2019年4月(1)
- 2019年3月(1)
- 2019年2月(1)
- 2019年1月(2)
- 2018年12月(2)
- 2018年11月(1)
- 2018年10月(3)
- 2018年9月(4)
- 2018年8月(6)
- 2018年7月(4)
- 2018年6月(1)
- 2018年5月(2)
- 2018年4月(2)
- 2018年3月(3)
- 2018年2月(1)
- 2018年1月(1)
- 2017年12月(1)
- 2017年10月(2)
- 2017年9月(1)
- 2017年8月(2)
- 2017年7月(1)
- 2017年6月(5)
- 2017年5月(2)
- 2017年4月(2)
- 2017年3月(3)
- 2017年2月(2)
- 2017年1月(2)
- 2016年12月(3)
- 2016年11月(2)
- 2016年10月(3)
- 2016年9月(4)
- 2016年8月(2)
- 2016年7月(4)
- 2016年6月(3)
- 2016年5月(1)
- 2016年4月(4)
- 2016年3月(3)
- 2016年2月(1)
- 2016年1月(5)
- 2015年12月(4)
- 2015年11月(5)
- 2015年10月(1)
- 2015年9月(6)
- 2015年8月(4)
- 2015年7月(1)
- 2015年6月(6)
- 2015年5月(3)
- 2015年4月(3)
- 2015年3月(2)
- 2015年2月(1)
- 2015年1月(3)
- 2014年12月(1)
- 2014年11月(1)
- 2014年10月(1)
- 2014年9月(3)
- 2014年8月(1)
- 2014年7月(1)
- 2014年6月(1)
- 2014年5月(3)
- 2014年4月(1)
- 2014年3月(1)
- 2014年2月(2)
- 2014年1月(1)
- 2013年12月(2)
- 2013年11月(2)
- 2013年10月(1)
- 2013年9月(3)
- 2013年8月(14)
- 2013年7月(7)
- 2013年4月(1)
- 2013年3月(4)
- 2013年2月(6)
- 2013年1月(6)
- 2012年12月(8)
- 2012年11月(6)