12月6号早上，接到项目经理的一个命令：要我单独开发一个可以实现每五分钟更新数据的Window Service。其具体逻辑就是从指定邮箱里面获取指定标题的邮件，并下载其附件；然后根据设定的密码对压缩文件进行解压；然后再读取文件中的数据，验证数据的有效性，有效后进行相应的更新操作。看起来貌似没啥难度，至少内心里面是这么想的。但是由于自己闲了大半年，心里还是有点虚，当项目经理问我需要多少时间时，我回答说到下周二（12月11号）应该能开发完。出乎我的意料：项目直接回复说到下周二测试完，心里那个狂汗啊。。。。。。
中午，由于还有一些不明确的地方需要跟客户进行确认，所以我只能先着手准备一些前期工作。建solution----->添加Window Service工程----->添加逻辑处理工程----->添加数据库连接工程。项目经理说让我可以参考之前的Window Service，于是我找到并打开相应的工程。人啊！一旦有了参考，就很容易想着照猫画虎，不去想其间的逻辑关系及联系。于是乎我照着其模样，手动的添加了ProjectInstaller Service文件，很纳闷：一个Window Service为啥要加两个Window Service文件呢？翻看了其cs文件里面的代码，也没发现其有任何的联系。也没多想就继续添加一些辅助的代码，很中规中矩的，及时的把注释加上，代码行数多的，每隔几行添加一行注释。代码添加一直持续到了7号下午，由于需求方面的也明确了，所以整体进度进行的速度还不错。开发过程中想着解压密码按灵活度来讲，应该是放到配置文件里面的，可是自己想要不先写死吧，到时候如果有此要求再改也不迟。速速的把主体逻辑搞定，其日志记录随后又给补上（不足的地方，想着等测试报了再说吧）。于是自己开始整体调试代码，结果很郁闷。报了一个Window Service Start Failure提示框，提示内容是：Cannot start service from the command line or a debugger. A Window Servcie must first be installed(using installutil.exe) and then started with the ServerExplorer, Windows Services Administrative tool or the NET START command. 一点击OK按钮就退出Debug模式了。这会我还没意识到其真正的原因，想当然的认为：可能是由于没有安装直接运行而导致报的错误。于是我拿出了调试Window Service的必杀招：在解决方案里面又添加了一个控制台工程，直接在主方法里面调用Start方法。调试还是蛮顺利的，发现几个Bug都给及时的修改。到了下午三点，感觉基本上没啥问题了，就开始向代码控制工具里面提交代码，并给项目经理说了，项目经理却说他现在没时间，等下周一（10号）再说。也没心思去测试，无聊的就到处看看新闻。好不容易到周五了，是该放松一下了。
到了周一早上，项目经理问我要了工程的检出目录，一会便发出来了一个安装包。我主动地上去下载了安装包，在本机上一安装就报：Cannot start service from the command line or a debugger. A Window Servcie must first be installed(using installutil.exe) and then started with the ServerExplorer, Windows Services Administrative tool or the NET START command. 直接傻眼了，这Window Service根本安装不上去么。各种求助于百度，google，都没发现有价值的解决方法。开始怀疑是不是VS 2005有问题，就用VS2010新建一个Window Service工程，各种模拟，也还是报这个错。痛苦啊。。。。。。心里真的很想求助一下项目经理，可是我又忍住了。翻找自己的技术资料库，找到了当年学习Window Service的资料，对照一看，差点吐血了。ProjectInstaller Service文件是系统生成的，而不是手动添加上去的。在主Window Service文件设计页面，右键点击里面有个添加安装，点击它之后就会自动生成这个文件。速速更改完之后就在cmd里面进行安装，结果还是报错：无效的字符在安装路径里面。我想是不是生成的exe文件里面命名里面用空格隔开每个单词导致的，于是速速把空格给去掉，再试，结果安装成功了，在Service列表中也能够找到相应的服务了。回到工程里面，把主Service的文件名称去掉空格，再次编译，查看生成的文件。我倒。。。。。。还是带空格的，这不是逼我么，把Window Service工程速速从解决方案里面给删除了，重新添加了一个不带空格命名的Window Service工程，把相应的文件加上去，编译生成exe文件，终于正常了。为了保险期间，自己在本机上进行了一次安装，结果安装成功。速速提交到代码控制器服务器上。并告诉了项目经理，让他帮忙给做一个安装程序。本想着这下可以清闲一下了，就等着测试报问题了。
令自己想不到的是，还等测试开始报Bug，项目经理就开始问我压缩包的解压密码是不是给写死了，我回答是，他毫不犹豫的地让我移到配置文件中去，还有提示信息也要单独弄到xml文件里面去。哎。。。。。。这些本来都是自己能够想到的，现在却不到测试就直接给报出来，看来这些在今后还是不要等他们说了，就默认是遇到此类的一定要给提出来弄成可以设置的。一顿狂改啊，终于在自己的精力集中下速速更改完。代码提交，又让项目经理给做了一个安装包给测试。可是又没过多久，项目经理又给我说少了三个逻辑判断，按照之前的逻辑来。我狂汗啊，明明记得自己都给弄全了啊，怎么还会有遗漏呢？找到之前的代码，每个方法查看后，平时认为哪个方法只验证非空及格式正确与否的方法里面，尽然还隐藏着逻辑方面的判断。哎。。。看来还是不能够太相信过去的经验啊。随后测试又报了一些日志方面的Bug，说每个参数值前面应该加上参数名。还有就是及时的换行等问题。
总结一下：这次的Window Service开发，让我知道这次的开发是失败的，系统经过两次大的改动才基本上完成了。今后开发一定要记得以下几点经验教训：
1、开发之前，一定一定要在大脑里面过下其主要流程，把能遇见到的问题及时提出来。
2、一些灵活的设置，一定要放在可以手动更换的位置。今后应该成为一种编码习惯。
3、开发完成的系统，一定用心测试一下。没有无缘无故的爱，也没有无缘无故的恨，相信代码是不会欺骗你的。
4、过去的经验固然很重要，但是为了慎重起见，还是放弃一些要命的经验比较好。
最后，希望自己今后能够牢记这几点，并永远用于工作中。