Coding is hard, you can make it easy!

前言

在前面两篇文章 记一次曲折的多资源文件拆分折腾过程（1） 和 记一次曲折的多资源文件拆分折腾过程（2） 中，已经把折腾过程中遇到的问题都弄清楚了。因为对这个问题印象太深刻了，而且 git 又是开源的，于是特地翻看了 git 的源码，并且在 windows 上用 gdb 简单调试了一波。

说明： 本篇文章适合 geek 阅读，全是一些源码查看及编译环境+调试的总结。

前言

本篇是上篇文章—— 记一次曲折的多资源文件拆分折腾过程（1） 的续篇。在上篇文章找到了导致编译报错的根本原因是 .rc 文件的编码不再是默认的 UTF-16LE-BOM 了。但是为什么 .rc 文件的编码会发生变化，并没有深究。本文继续探究一下。

缘起

最近这些天，我一有时间就捣鼓 .rc 。用 git 管理过 .rc 文件的小伙伴儿应该都知道，.rc 文件会被 git 默认当作二进制文件来管理。每次合并代码的时候，只要涉及到 .rc 文件的变更，很大概率会报冲突，而且工具不能很好的解决，只能手动解决。为了解决这个问题，我想到了两个方案：

1. 让 git 把 .rc 文件当成普通文件来管理。
2. 把一个大的 .rc 文件拆成多个小的 .rc 文件，这样可以有效的降低冲突的概率。

这两个方案相互之间没有任何冲突，所以这次折腾的时候，这两个方案是同时进行的。本以为没什么值得写的，没想到收获了意外惊喜，于是有了本篇总结。

缘起

因为需要分析 tfs 提交日志，并按照一定条件（比如，提交信息或者用户名）分类整理，特意写了这个小工具。在使用过程中发现，某些情况下会花费很长时间才能返回处理结果，当时稍稍做了一些优化，已经能满足当时的应用场景了。但是在处理大文件的时候依然会花费很长时间。忍了这么久了，终于有机会做一次效率优化了。

缘起

目前开发是在华为云桌面里进行的，在远端机器上装了 v15.05 版（很老的版本了）的 process explorer。但是今天打开 process explorer 后，Process Name 列消失不见了。

缘起

前一段时间，想使用 .net 监听特定文件夹中的文件是否发生变化。网上一搜，可以使用 .net 官方提供的 FileSystemWatcher，很开心的写好了代码。随着使用的不断深入，发现了 FileSystemWatcher 几个不够完善的地方。比如，

1. 事件触发时，文件可能还不能被访问。
2. 如果监听选项设置的过多，则有可能会触发多次文件变化事件。
3. 监听过滤器不够灵活，我没找到同时监听多种特定文件类型的方法。比如，同时只监听 .docx 和 .bmp 文件。

鉴于此，基于 .net 官方提供的 FileSystemWatcher，我又封装了一个新的类。可以在一定程度上解决以上几个问题。

前言

前几天，同事在 .net 程序中，遇到一个很 “诡异” 的问题：明明两个值是相等的，可偏偏却不相等，这是怎么回事呢？

缘起

磁盘已经全面爆红很久了，使用 dism++ 清理了几次，依然很紧张。终于，昨天在编译程序的时候又因为磁盘空间不足失败了！是可忍熟不可忍。必须安排！

缘起

前阵子，朋友遇到一个 .net 程序启动不起来的问题。根据之前的经验，一般是依赖的动态库加载失败导致的。或者找不到（依赖的动态库没有放到相应的目录下，一般放到应用程序所在目录即可），或者不匹配（64 位的程序加载 32 位的动态库，或者 32 位的程序加载 64 位的动态库）。整个排查过程并不复杂，本文不打算介绍整个排查过程，而是想介绍一些 .net 程序的基本常识（比如，以 Any CPU 编译出来的程序，是 32 位的还是 64 位的？），还会介绍几个我认为不错的查看工具。

缘起

前几天，修复 bug 后，本地测试通过，提交代码到 tfs，关闭 bug。但是客户拿到程序后，效果依然不对。来来回回检查了好几遍，逻辑是正确的，本地验证通过了，代码也确实上传到 tfs 了，但是程序到客户手里，效果确实不对。如果是你，该如何调（shuai）查（guo）呢？

说明：本文只是分享一种排查问题的思路。