接手了一个系列的C#工程。 程序编译完，都是正常运行的状态。偶尔会维护(修bug, 写几个C#插件DLL). 老大只让干活，不给时间停下来休整一下(系统的看下书)，这也是有点为难。 不过，作为没学过的语言，能在不看书的情况下，能维护，也行了。
当时遇到一些简单的调试问题，因为对C#没系统看过书，遇到问题就要请教以前离职的同事，也是挺尴尬的。 不是问题的问题，非要请教别人… 虽然还是没时间去系统的看C#书籍，但是我遇到的调试问题，我已经通过实验搞懂了。 能调试了，那剩下的都不是问题。
首先，要将C#工程设置为debug版，带调试符号 其次，需要将带接口的工程(dll), 指定输出路径， 重新编译一下，编译后，生成在我要用到的部件调用的dll位置。 而不能是将生成的dll, 拷贝到我需要的位置。 这样遇到接口调用时，F11就可以进入接口单步调试其他部件(dll).
至于不能拷贝dll到指定位置，我想是pdb中指定的调试信息为相对路径。当拷贝dll到另外一个目录时，IDE无法找到调试信息中指定的源码文件，所以只能步过。这只是猜测，还没有验证。
还有一种可能性是，dll和源码分离一段时间后，可能源码工程被动了，由于dll和源码不匹配，所有不能F11.
因为没系统的看过书，如果dll中实现的有问题，开始的做法，是将dll中的代码摘到一个新的C#exe中，修改后再测试。 很麻烦，搞的很烦。
今天发现，可以新建一个C#exe, 加入引用(指定dll和dll依赖的部件即可)来测试。 然后 using 部件的名字空间 这时，就可以new部件中的类了 用new出来的类，直接调用C#dll中的方法。 虽然也需要改一点(毕竟测试程序的逻辑和真实的业务逻辑是不一样的)，但是工作量非常的小了，感觉非常好。
using System; using System.Collections.Generic; using System.Linq; using System.Text; using ns_my_dll; namespace ConsoleApplication1 { class Program { static void Main(string[] args) { test_case(); } static void test_case() { System.Console.WriteLine(">> test case\n"); MyDevice dev = new MyDevice(); dev.only_for_debug(); // 在dll中，将真实业务逻辑的地方不执行，只执行测试逻辑 dev.Init_dev(); // 调用dll中的接口，初始化dll中的变量和环境 // 添加引用时，必须直接引用DLL工程输出目录的那个最新刚编译出来的debug版DLL, 才能F11单步进入 // 如果将这个debug版DLL, 拷贝到测试工程的目录下，是F11单步不进入的, 单步了，也是步过 // 30 33 36 30 30 30 39 32 42 30 39 32 46 30 39 32 34 30 38 39 38 20 20 20 20 20 20 20 20 30 31 30 39 20 20 20 20 20 20 20 20 20 20 20 20 31 33 38 32 20 20 20 20 20 20 30 30 46 34 39 42 byte[] b66 = new byte[] { 0x30, 0x33, 0x36, 0x30, 0x30, 0x30, 0x39, 0x32, 0x42, 0x30, 0x39, 0x32, 0x46, 0x30, 0x39, 0x32, 0x34, 0x30, 0x38, 0x39, 0x38, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x30, 0x31, 0x30, 0x39, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x31, 0x33, 0x38, 0x32, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x30, 0x30, 0x46, 0x34, 0x39, 0x42 }; dev.proc_recv_cmd_0x66(b66, 0x66); // 测试通过 System.Console.ReadLine(); } } }