今天刚接手一个新模块的开发，内容并不复杂，是Batch的开发代码。
将现有的代码试着Debug了下，根本跑不通。这种情况在开发中已经不是一次两次了。尽管如此，还是让人头疼，有时要花好几个小时，甚至一两天来才能找出原因。当然十之八九都是配置上面的问题。而我还是花了2个小时才找到问题的根源。
这里简单描述一下今天碰到的问题及过程。
前提：新开发的情况下，通常会使用新的DataBase（数据库）。
将整个BATCH分为3个部分，GUI（画面显示），BL（业务逻辑），DB（数据访问）。隔离开GUI,BL,DB三者，是普通的代码架构。三者之间的联系如果简单，可以直接在代码中增加新的Project或者Class进行专门处理（DBConnUtity）。涉及到DB数据，不可避免要进行配置设定，如，SQLSERVER, DataBase，ConnectionTimeout，AliveTimeOut，MaxPool，MinPool设置等。
当DBConnUtitiy 和Batch在同一个Solution下时，如果调式出问题，逐步Debug追踪的话，问题通常能够较容易找到。而有很多系统将DBConnUtity作为一个共用DLL（由其它我们不知道的Solution下编辑而成）。这个时候如果我们只有封装的DLL文件，无法进行深入Debug。也无法知道具体是哪儿配置文件出错了。这个时候只有试图摸索前行了。
1. 分析异常：如果共用DLL写的严密，会做一些基本的Catch和ERROR解析，通过分析一般可以发现问题。今天我碰到的是一个没有做返回Error及产生LOG的。
2. 配置方法：通常同一个大系统下，各种配置方法会一致。比如将配置文件放在根目录下的Conf文件夹下。通常有些，DB.xml（DB.ini），Message.xml（Message.ini）等类似的文件。以此推理，共用DLL中使用的Config文件，是否有问题？
3. 调查已发布的应用环境：当前正在被客户使用的系统，自然各种配置方式是当前相对正确的（当然有很多新手是不会被允许接触客户的主机），可以作为参考。当然第一反应是，看一些类似于Common，Tool，Config等文件夹的属性。（如果是Web开发的话，有时有必要看看Js下的一些文件）
4. 咨询老同事：同一个项目里有人最好，没人可以问其它项目组，或者其它老员工。环境配置问题通常是一个共性问题，其它开发人员极有可能碰到过。即使没有碰到过，开拓下想法给自己一个新的思路，自然是好事一桩。
今天发现问题后，第一时间修改了XXX/Bin/Config下的DB.ini文件（因为更换了DataBase名，潜意识里这里肯定要修改），再试着跑了一次还是同样的问题。随后查看参照下的共用DLL路径，也是XXX/Bin/下，第一步预想今题不是配置问题因此的。有些纳闷了，本项目组就2个人，我和一个客户系统维护人员，问了维护老同志，他看到是开发环境，一时也给不出好的建议，就提出让我看看发布的应用环境，因为要通过VPN链接客服主机，账号权限问题嫌麻烦，我问他要共同DLL的代码。找到代码，后单独编辑后，将生成的共同DDL拷贝到要执行的Batch中，然后逐步调试。
最后到了DBConnectInit方法时候报错，饶了一圈还是配置问题。已经改过了，那就是该错了地方。仔细看了环境当前的Batch是Release环境下进行的编译，而我修改的Debug目录下的Config文件。再次执行了一把，顺利通过，问题解决。但是出现这次问题还有一个原因，就是.csproj.user文件经常被修改，而无需保存到代码管理器中。
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
<StartArguments>5372662</StartArguments>
</PropertyGroup>
</Project>
经过积累和整理的知识，才是智慧。这句话值得每日回味。