dll不匹配的bug

为了这个bug，找了两天，结果很简单，为什么会找这么久呢？代码不是我写的，里面的业务逻辑也不清楚，所以看代码也是很费劲。不能本地造出那个环境。最后没有办法，只好加日志，丢dll，分析日志，通过这样的方式来定位问题到底出在哪里？

首先必须说，前一个同学加的日志真的是非常有帮助。加的非常详细，每一步都加了。否则我在加第一次日志，并没有定位到问题之后，我将会加很多次日志才能找到问题。

当然我加的日志，也很暴力，全部序列化为json，直接拿对比工具对比。肯定就发现有所不同。

另一方面，写代码的同学水平也是比较高，虽然细节看不懂，但是我知道有另一个地方，处理代码的逻辑跟这个地方的前面部分是一样的，而且参数也很相似，只是继承了一下加了一些参数，方法都是同样的方法。虽然前面加的json日志很详细，但是我仍然不能很快定位问题在哪里，并且由于数据量庞大，有些地方根本没法加日志，只能根据入参，去分析，这个就比较耗时了。我也不想这么做。所以我就来了一个最简单的办法，比较两个相似的接口的入参，结果被我发现，有一个参数值不一样。然后直接把这个参数改了，丢去测试一下，结果正确了。后面更详细的分析，我也就没有做了。

直接把当时有参与过的同学拉过来问，这个参数是怎么回事，结果她说，这是一个限制参数，在这里应该是不限制的。而且她在基类的无参构造函数里面也写了默认为不限制。

查了调用这个WCF服务的地方，根本没有一个地方用过这个参数，也就是说这个参数就是一个默认值。但是为什么跟她写的不一样呢？

推测可能是dll不匹配，丢了一下最新dll，问题解决！但同时为防止万一，直接在方法的入口处重新写死，并加上注释!

我一直记得，C#的构造函数是不继承的，所以我认为在父类初始化，对子类不会有任何影响，结果我写了一个test测试出来，结果是C#构造函数是不继承的这一点是对的，但是在创建子类对象的时候，它有一套执行顺序，这一点必须要注意，会先执行父类的构造函数，如果没有的话会报错，再执行子类的构造函数，如果子类和父类都是带参构造函数，则必须用base调用，否则会报错。