只买对的，不选贵的！

如果你是一位理性的消费者，你应该遵守这一原则。商家总会想一切办法让你相信，他的最新产品是最好的，是最适合你的。然而，他的很大一个目的就是想要你口袋里的Money，当然他的新产品也许真的很不错。但我们应该理智一点，仔细的判断一下：这是你必须的？还是你想要的？（呵呵，这跟编程有鸟关系？！！）
OK，前两天在CSDN上看到一文，是讲述MS中国在北京做的一次技术宣传会。里面说到，就连MS自己的技术宣传人员都到MS的新技术太多太杂了，他们不得不花大量的时间去学习和了解这些新东西，更别说那些准备使用新技术的开发人员了。不是吗，大家应该深有体会，就在.Net上，短短几年时间，从1.0到3.5，一下子好几个版本就出来了，同时也带来了一些新的技术。什么ASP.Net，Ajax(MS的开发包)，托管C＋＋，SQL2005（托管的），DirectX（托管的），还一个SilverLight等等，开发平台也从VS.Net2002到2003,2005，还有已经Beta2了的2008。Oh，my God！你“买”得起这些吗？
永远别相信商家的话，自己须要的，才是最好的。当初我学习和使用C＃(Framework 1.1)的时候，确实下了很大功夫，看了不少书，特别是一些关于程序性能与运行平台的内容。当初我对C＃不了解，是从C开始学起，然后学C＋＋，后来再学的MS的VC，然后才是C＃。当时真的以为C＃就是C＋＋的一个升级，而且很多书都是这样写的：C/C++/C#，看看吧，他们三兄弟还真像会事。当然，也有一些书把C＃和Java对比的，可惜Java的书我只看过一本，对它不了解，所以作者怎么去比，我就看不明白了，但有些作者既然让我先去学Java再学C#，oh, my God，这作者真的混蛋。还好我没听他的。
回忆一下当时我看的一些书的里的内容吧。先是安装开发平台，VS.net2003以及Framework，当然当时只有两个版本可比较，一个Beta版（其实也就是2002，先在这里说一下，还有一些大型公司在使用2002版的开发平台）和一个2003。然后就是机器的最低要求（永远的骗局，全世界骗人最多的，最真实的慌言），程序的跨平台性（当然，得要安装Framework，然而它的版本成了我最近很郁闷的事情，后面再说），再就是版本控制，DLL陷阱，代码安全等一些问题。
OK，我并不是一位权威的专家，只对上面这些问题说说我最近的一些体会吧。我用VS.Net2003＋Framework 1.1开发有近4年时间了，从ASP.Net到WinForm，从JS脚本到SQL存储过程，大大小小代码写了也近有近20万行了，读的代码应该过百万行了，相信对这些还算是了解一点点的。想当初开始用2003开发应用程序时，从来不用考虑版本问题，不就是安装一个.Net Framework吗，而且MS的网站上直接可以下载，而且做的安装包里会先自动检测这个依懒。MS真是想的太周到了，生怕我们不知道用C＃.Net开发的程序要Framework的运行平台。还好，我只用跟别人解释一下，安装一个扩展包就行了。客户再要问什么，我就说是一个MS的补丁。还好，后来的XP补丁里还真的把.Net1.1给打上去了。好了，这样就不用担心客户机上没有.net平台了。算是松了一口气。
然而最近却发生了一件很不幸的事。因为.Net Framework版本的升级（它升的很快，比我的工资快多了），我们不得不考虑版本问题了。最开始我相信MS的一贯作风：向下兼容。而且这次我也有理由充分相信MS在.Net的版本问题上会比其它任何产品的版本问题解决的都要好。然而，我不得不说这是一个很大很深的陷阱！！！
由于Framework版本的升级，在不同版本下的开发的程序也出来了，当然还有很多第三方控件。因为这些程序和控件所依懒的.Net版本不同，因此就意味着目标机器上要安装不同的版本。不错，MS是说了它的版本不冲突。然而，不冲突的牺牲是什么呢？严重的性能损失。我看来看一个很有可能发生的假设（其实我就遇到了，只是没这严格）：一个应用程序用1.1开发的，使用了第三方公司的一个2.0下的数据持久层控件，又用到了另一个第三方公司的界面库，很不巧，这个界面库是3.0的。没错，我们完全可以把程序配置起来，让它来运行！
我们先来看看运行条件吧：Framework1.1，2.0，3.0都得安装！！！！（MS想的太好，不冲突）。而且还有一个好事，就是3个随便先后顺序安装都没问题。Oh, my God! 他们三个好像谁也不认识谁！确实是这样的，谁也不与谁相关，完全独立！好吗？
看看程序运行时的状态吧：加载程序集XXX1.1, 加载程序集XXX2.0, 加载程序集XXX3.1,呵呵，这下有戏看了，同样的一个程序集，版本不一样，加载了3次（这里是假设，但我确实跟踪到加载了两个的），为什么？因为第三方公司的控件里的引用只认它自己的版本，确切的说，是唯一的一个文件（在为Public Key的原因，能且只能引用唯一的文件）。OK，再来想象一下多几个版本，多几个控件的问题吧？最后GAC里的程序集你要加载多少才能运行一个程序？（我都不敢想了，这比DLL陷阱可怕多了）或许我说的有一些夸张，但下面这种情况是一定存在的：1.1，2.0。3.0的几个程序同时运行，或者先后运行！同样也存在上面的程序集加载问题。呵呵，只好苦笑了吧！
再来看一下安装吧。我遇到过这样的一个问题：用1.1做了一个安装Merge，然后用Install Shield把它合并到一个非托管程序的安装包中。然而不幸的是，运行Install Shield的机器上安装的是.net Framewore2.0，它在合并安装包时，以2.0的要求给我合并了我的Merge，然后安装到了目标机器上。OK，安装一切正常，自动给检测和安装了Framework。不幸，真不幸，它给我安装了2.0。结果是程序无法运行，因为没有Framewor1.1的运行库！讽刺，真够讽刺的！！！！难以想象遇到更高，更多版本的时候会是什么情况！我真的不敢想了，4.0，5.0……？？？
再来看一下自己写的程序的版本问题吧。我在做序列化时遇到这样的一个问题：如果某个文件是以a.DLL，1.0版本为基础进行的序列化，那么请你注意，这个文件就和这个a.DLL(1.0)永生绑定了(当然，如果你直接用二进行制来读取这个文件就不在讨论之列了)。当你把a.DLL文件修改了文件名后，不好意思，序列化文件就无法反序列化了。当你不小心把版本号从1.0修改到了1.001，不好意思，文件也不能反序列化了！怎么办？！听MS，让这几个DLL文件共存，然后用1.0反序列化文件，再用升级后的程序重新序列化成高级版本可用的文件！Oh，可怜的程序员，可怜的程序，这意味着程序的发布的每个新版本中，如果有我说的这上问题，那就必须在新版本中包含旧版本的文件，以及升级工具！（55555，我想哭呀，是每个版本呀！）最后我怕了，只好把版本号统一固定，不能随便修改！然后自己再对序列化与反序列化进行控制，这样就可以使用旧程序生成的文件了。（注意：不仅是文件序列化与反序列化，这个问题同相也存在于其它序列化当中，例如网络流的序列化，内存流的序列化等，因为安全性问题，序列化与反序列记录了序列化的依懒文件和版本以及Public Key，就意味着如果一些DLL文件的丢失，你就永远无法反序列化数据文件了，当然还可以用其它方法来读取，但如果是经过验证后的序列化文件，那你就可得先学学密码学再来读取这个文件吧，反正我是没办法读取的）
VS.2005是安装了，可是没敢用。它太“贵”了，为之付出的东西决不仅仅是一个开发环境的升级和一些所谓的版本兼容问题。2008又像春风一样吹来了，我都没敢去下载！我觉得我还算是有点理智的，选择必须的就行了。
VC6.0近10年了，大多数VC++程序员还在用它，因为它是对的，而且不“贵”！2003虽然把托管C＋＋“吹”的神呼奇神，然而那些经过多年锤炼的VC＋＋程序老手们还是坚持在使用他们最好的东西（并不是瞎说，我们公司的所有C＋＋程序的机器上都安装了.Net 2003，但开发却只用VC6.0，而且我从网上下载的一些C＋＋例子与一些SDK，都是基于VC6.0的，2003好象与C＋＋说Bye-bye了，后面的版本就更不用说了，还把什么Silver Light都搭上了，却不搭个必须的单元测试或者代码重构之类的东西，MS真是太会卖东西了）！
好了，VC我是暂时没机会使用的了，但对于.Net，我还是觉得2003，1.1是一个比较便宜的东西，而且是我目前必须的。
基于这一原则：只买对的，不选贵的！我想我还是可以坚持使用2003好长一段时间的。一些商业炒作，过些时候就知道了什么是好的了！