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

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

TL;DR

用CodeProject上的帖子的实现, 传入主程序路径, 检查图标个数, 将首个图标给需要的主窗体.


扯一扯:

有点.net开发经验的人都应该知道: Winform窗口图标和exe文件图标不是同一个东西,

假如有需要使用同一个图标的情况, 那将会保存两份数据, 令有强迫症的人(比如我)抓狂.

之前有折腾过Windows图标相关的操作, 这次也轻松提取主程序图标然后应用到主窗体上.


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

标签: 软件开发 C# Interop Winform

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

活久见:表达式树编译执行引发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) 浏览(101)

[成功]又一次自己编译Mono,这次是在Windows上,玩Bundle

作者:V君 发布于:2017-10-30 21:07 Monday 分类:折腾手记

目标 -- 将 .net 应用程序用只用一个 exe 承载, 并极大缩减体积, 且能保证工作正常.


(这次不是针对性的解决问题, 不TL;DR (´∀((☆ミつ 


篇幅较长, 进来看

阅读全文>>

标签: 软件开发 C# 命令行 mono 软件故障诊断

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

批量下载在漫画的通用解决方法,包括脚本生成内容

作者:V君 发布于:2017-10-25 13:43 Wednesday 分类:折腾手记

TLDR:

由于太过简单(也就百来行代码),写得还有点丑,就不传到SVN上了 (´∀((☆ミつ

流程大概如下:
  1. CsQuery解析HTML
  2. jurassic解析Javascript
  3. Newtonsoft解析Json对象
  4. PLINQ多线程下载图片文件

进来听我扯扯

阅读全文>>

标签: 软件开发 javascript C# Chrome 爬虫 HTML Web技术

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

尝试在Windows NT6+上免驱实现FUSE

作者:V君 发布于:2017-9-22 20:18 Friday 分类:折腾手记

■前言  (这次不是解决问题,因此没有TLDR(´∀((☆ミつ)


首先简单解释一下 FUSE 的定义:

在用户空间实现的虚拟文件系统, 能够让标准文件系统API访问,

只是某个路径在应用程序的控制之下, 还没到达虚拟块设备的级别.


FUSE 能够实现许多有趣的功能, 比如挂载压缩包, FTP, MTP, 甚至 Ramdisk 都能实现.

在 linux 实现 FUSE 可以说是相当容易,

由于 linux 可以把 FUSE 功能集成到内核, 随便 mount 就可以了.

然而 Windows 内核并没有这样的功能,

只能以虚拟设备来创建虚拟盘符或挂载到 NTFS 装入点亦或者建立目录符号链接.

 

现状


在 Windows 实现 FUSE 通常需要虚拟驱动器来实现, 这需要驱动程序来支持.

现成的软件有

1)免费的 WinMount(生死未卜)

2)收费的 NetDrive.

它们都是封装好的产品, 用户不能定制自己的功能.

可以自己实现接口的驱动组件有

1)开源的 Dokan(貌似不太稳定)

2)开源的 WinFsp(没用过,无法评论)

3)死贵死贵的 CBFS.

早些年把玩过Dokan, 虽然提供了.NET的接口, 且实现难度还不算高.

假如接口实现得不稳定, 没妥善处理好异常就可能会引发蓝屏, 这也就是本文的初衷.

-- 不使用驱动来实现 FUSE , 就算接口实现得再糟糕也不会把系统搞崩溃.

 

摸索


稍稍有点经验的 Windows 用户都知道,

资源管理器可以直接访问FTP或多媒体设备存储(MTP/PTP)

可以把路径以文件夹的形式图形化呈现, 

然而这些路径并不能够使用标准文件系统 API 来放访问,

不能用 WindirStat 来统计 MTP 上的文件夹占用情况.

尽管资源管理器双击能打开这些路径中的文件,

其实背地里还是先复制到临时文件再调用关联的应用程序去打开.

 

其实 Windows 还是可以不依赖驱动就能实现 FUSE 的.

目前发现了两种方法, 尽管都是利用网络共享绕一圈, 还蛮折腾的:

1)基于 HTTP 的WebDAV 协议

 在一次折腾如何在安桌手机 USB 的 MTP 模式使用 WinDirstat 的过程中

 发现了 WebDAV 共享 APP.

 安装并启动之后, 按照步骤创建映射盘符, 能被 WinDirstat 访问了.

 咕狗了解到是基于 HTTP 的共享协议.

 (这是WebDAV over WIFI, 这已经和 MTP 没关系了, 不过下文还是会和MTP有关系)

 这才发现 Windows 还有这种共享方式, 支持标准文件系统 API, 

 只是实现机制略坑, 性能略糟糕.

2)Samba 局域网共享

 不解释太多也不会被打 (´∀((☆ミつ

 需要实现一个 SMB 服务端, 还要战 445 端口. 战? 不是占? YES, 稍后娓娓道来.

 

尝(zhe)试(teng)


□WebDAV -- 这货是真FUSE, 只是 Windows 实现机制太坑人


知道这货基于 HTTP 之后, 当然就是去找找看有没有人已经做成类库, 而不是先自己啃RFC.

放狗出去找到两个类库, 分别是 SF 上的 WebDAV.NET 服务框架 和 GitHub 上的 WebDAVSharp.

这次选择了后者, 只要按接口做实现, 就可以达到目的, 咋一看还挺完善的, 只是性能有点慢.

即使用内存来实现后端文件存储, 访问速度也和硬盘差不多,

监视性能才发现, 原来 Windows 在背后依然用临时文件的方式暂存 WebDAV 上面的文件, 

只是重定向了一下文件系统. 难怪这么慢, 这 FUSE 虽然是真货, 但却掺了水.

你可以把它的临时目录(↓)链接到 RAMDISK 以提升性能, 此目录必须存在才能正常操作文件.

C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp\TfsStore\Tfs_DAV\

只不过这样就失去了用 WebDAV 实现 RAMDISK 的意义, 只能用作简单 FUSE 玩玩.

顺便再贴一个之前还没了过背后原理, 仍未知性能坑时, 实现MTP2DAV

 

Samba -- 战445端口要不要太折磨人?


非常幸运地找到最近 TalAloni 用 .net 实现且一直在维护的 Samba 服务端的库 SMBLibrary.

看了下介绍, 确实有提到可以实现虚拟文件系统. -- 只是 445 被 Windows 锁死, 需要一战.

除非禁用 Server 服务, 否则全部适配器的 445 端口将不可用...见爆栈.

尝试了许多诸如增加虚拟适配器的 trick 做法, 然而并没有设么卯月...

停止 Server 服务之后还不行, 445 仍然会被 System 占用, 需要重启...

那就只能彻底禁用了.禁用了 Server 服务并重启之后, 445 端口总算可用.

把内置的目录共享跑起来, 效果还挺理想, 性能相当不错, 看了一下接口并不是很复杂.

就简单做了个后端用内存支撑的 RamDisk 实现, 然而并不是很理想.

-- 非常不稳定, 常规操作下会出现各种错误, 看来是接口适配的不太妥哇...

总之, 这种 Samba 的方式是可行的.

只是稍稍麻烦点, 无论是从禁用 Server 服务还是实现接口上来看...


■结论


WebDAV 可以用来实现简单的 FUSE, 无法考虑性能.可以用 RamDisk 稍稍提升一下.

Samba 性能相当好, 接口略复杂, 目前还没啃透 (´∀((☆ミつ

标签: C# Winform NAS HTTP 传输协议 FUSE VFS Windows

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

Powered by emlog 去你妹的备案 sitemap