V君的博客

通过NuGet.config改变packages目录位置

作者：V君 发布于：2018-4-12 15:45 Thursday 分类：挖坑经验

TL;DR: 在解决方案文件旁边创建一个 NuGet.config 文件,里面指定 repositoryPath .

参考: M$DN 爆赞 

不扯,继续搬砖 (´∀((☆ミつ

标签: 软件开发 VisualStudio

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

高德WEB地图的坑: 首个标注在创建后无法立即获取DOM

作者：V君 发布于：2018-3-27 12:10 Tuesday 分类：挖坑经验

TL;DR 

创建地图实例之后不管三七二十一先创建一个不可见的标注.

自从第二个标注开始你就能顺利在创建之后立即拿到DOM了.

 

不扯了, 已经被折磨到不要不要才摸清套路.

标签: 软件开发 javascript Web技术 GIS

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

ASP.NET WEB场:在使用StateServer站点集群节点之间共享会话

作者：V君 发布于：2018-3-22 17:31 Thursday 分类：挖坑经验

TL;DR

步骤1: 在每个节点部署的web.config里配置状态服务为StateServer,使用一致的主机和端口;

步骤2: 为每个节点IIS网站设置一致的ID.

扯一扯:

终于有机会接触ASP.NET的WEB负载均衡, 运维配置好测试环境之后开始捣腾.

按照公司沿袭下来的习惯,用的是歪门邪道的nginx反向代理实现请求分发.

说到会话,当然就是登录状态啦! 一上来就掉进坑里: 登录不了.

诊断下来发现, 原来死循环重定向了: 因为节点之间会话不通,

导致节点A处理完登录之后回到节点B处理的首页,节点B没有得到会话判定为未登录

接着又重定向到节点A处理的登录页面, 登录页面会把已登录的请求重定向回首页.

如此反复, 甚是尴尬.

经过一番咕狗,找到M$DN上的帮助文档(325056),开始按照文档操作(这里又一次自己跳坑里).

由于错误理解帮助文档中所指的路径,误以为是部署web站点的文件路径要求一致,

尝试了之后发现不行,又回来仔细读文档. 这才发现要一致的是网站ID.

0rz.

标签: 软件开发 ASP.NET 负载均衡

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

Winform小技巧:让窗体直接使用exe图标(PE资源),避免重复嵌入图标资源

作者：V君 发布于：2018-3-20 17:52 Tuesday 分类：挖坑经验

TL;DR

用CodeProject上的帖子的实现, 传入主程序路径, 检查图标个数, 将首个图标给需要的主窗体。这里有个例子把代码搬进去就能用

扯一扯：

有点.net开发经验的人都应该知道：Winform窗口图标和exe文件图标不是同一个东西。假如有需要使用同一个图标的情况, 那将会保存两份数据, 令有强迫症的人(比如我)抓狂。之前有折腾过Windows图标相关的操作, 这次也轻松提取主程序图标然后应用到主窗体上。

PS. 这种方式可以支持多尺寸图标, 简单调用系统API的ExtractIcon不支持。

偷偷更新一个极端案例，顺便吐槽一下 TalAloni 酱。因为 ta 给每个窗体都使用了重复的图标，导致最终文件体积骤增，若不把是 ilmerge 换成 ilrepack 之后成功打包，还没发现居然超过了 3MB！回来检查体积来源就发现了每个窗体的 resx 文件都有 500KB ，接着发现了重复的图标文件。

标签: 软件开发 C# Interop Winform

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

活久见:表达式树编译执行引发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 运行时错误

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