面对VS2005，我遇到了BUG？
产品开发一直计划使用2005，终于能成行是件高兴的事情，但期间遇到几件怪事情：
1——
ICO编辑器无效。
通过IDE编辑ICO文件，能编辑，也显示保存成功，但再打开，数据还是原来的，郁闷。
现在要编辑ICO都是回到2003来处理。
2——
TRY-CATCH-FINALY的无奈。
TRY的目的是为了捕获异常，或者为了调试，或者为了避免不必要、不确定的麻烦
CATCH是为了处理TRY捕获的异常
FINALY是为了进行最终的处理，无论TRY后还是CATCH后都要执行。
原则上说，TRY-CATCH后，FINALY的存在是意义不大的，只要把FINALY提出来，放置在TRY-CATCH的后面就OK了。所以我很少用FINALY。即便CATCH没有什么东西也会用CATCH来完整TRY语句。
当然，FINALY的最大作用就是TRY-CATCH或单纯的TRY后无论是否抛出异常都会执行，而放置在TRY-CATCH语句后面的代码在遇到异常后是不会再执行了。
现在遇到了问题，估计是2005改进的吧，哈哈（也可能是我一直没有遇到这样的情况吧）。
曾经在2003下面的代码，只使用了TRY-FINALY，还从来没有发现过错误，现在2005却经常这样，TRY后把异常抛出了，只好修改为TRY-CATCH-FINALY。
是我把TRY-FINALY理解错了还是……
3——
2005的IDE超长的等待处理，烦死人。
情况是这样的：编译后，如果没有错误还好些只要有错误，那么编译完成后都要等很久才会有反应，为什么会这样？本人猜测可能是重构技术导致的吧，又或者内存少了（512M，现在到768M还是一样）？如果因为这样关闭重构功能，那2005提供重构就有作秀的嫌疑，因为重构严重影响了开发进度。
另外一个情况是：如果使用了FORM设计操作，那么，无论是否编译成功都会出现上面的等待时间超长的情况，又是什么原因？这个时候还跟重构有关？
第三个情况就是：打开WINFORM窗体（包括WEBFORM）都会出现等待时间很长的情况这个应该跟重构没有关系了吧？2003可是没有这么严重的。
第四个情况：执行可视设计时，对引用到的模块的版本太敏感了，只要项目和引用到的项目或DLL中有2个以上的对象引用到的同一个项目的版本不完全一致就没有办法设计界面，2003好象不是这样的。
很喜欢2005里面的项目清理支持，以前都要关闭解决方案，甚至要关闭IDE，然后手工删除OBJ下面的中间文件，现在不用了哈。
1——
ICO编辑器无效。
通过IDE编辑ICO文件，能编辑，也显示保存成功，但再打开，数据还是原来的，郁闷。
现在要编辑ICO都是回到2003来处理。
2——
TRY-CATCH-FINALY的无奈。
TRY的目的是为了捕获异常，或者为了调试，或者为了避免不必要、不确定的麻烦
CATCH是为了处理TRY捕获的异常
FINALY是为了进行最终的处理，无论TRY后还是CATCH后都要执行。
原则上说，TRY-CATCH后，FINALY的存在是意义不大的，只要把FINALY提出来，放置在TRY-CATCH的后面就OK了。所以我很少用FINALY。即便CATCH没有什么东西也会用CATCH来完整TRY语句。
当然，FINALY的最大作用就是TRY-CATCH或单纯的TRY后无论是否抛出异常都会执行，而放置在TRY-CATCH语句后面的代码在遇到异常后是不会再执行了。
现在遇到了问题，估计是2005改进的吧，哈哈（也可能是我一直没有遇到这样的情况吧）。
曾经在2003下面的代码，只使用了TRY-FINALY，还从来没有发现过错误，现在2005却经常这样，TRY后把异常抛出了，只好修改为TRY-CATCH-FINALY。
是我把TRY-FINALY理解错了还是……
3——
2005的IDE超长的等待处理，烦死人。
情况是这样的：编译后，如果没有错误还好些只要有错误，那么编译完成后都要等很久才会有反应，为什么会这样？本人猜测可能是重构技术导致的吧，又或者内存少了（512M，现在到768M还是一样）？如果因为这样关闭重构功能，那2005提供重构就有作秀的嫌疑，因为重构严重影响了开发进度。
另外一个情况是：如果使用了FORM设计操作，那么，无论是否编译成功都会出现上面的等待时间超长的情况，又是什么原因？这个时候还跟重构有关？
第三个情况就是：打开WINFORM窗体（包括WEBFORM）都会出现等待时间很长的情况这个应该跟重构没有关系了吧？2003可是没有这么严重的。
第四个情况：执行可视设计时，对引用到的模块的版本太敏感了，只要项目和引用到的项目或DLL中有2个以上的对象引用到的同一个项目的版本不完全一致就没有办法设计界面，2003好象不是这样的。
很喜欢2005里面的项目清理支持，以前都要关闭解决方案，甚至要关闭IDE，然后手工删除OBJ下面的中间文件，现在不用了哈。
