起初，NuGet很好用。输入一个update-package，所有包的更新工作都自动完成了。很方便，我是这么相信的。
但是在团队开发中，一个问题开始浮现：
- 我们应该把packages目录签入源代码控制吗？
如果不签入的话，那么项目里的其他人就会遇到麻烦——他们没有办法编译，update-package也无效（因为更新命令只检查packages.config，并不检查包文件是否真的存在）。同时，CI服务器也会马上报错。但是签入的话，对我们无用的文件太多了，无谓地增加版本库的大小。虽然这不是不能忍受的问题，可是感觉上确实很不爽。
在网上搜索了一下，发现其他很多人也在问这个问题。NuGet开发团队的解决办法是，在Solution级别增加一个Enable NuGet Package Store的命令，通过自定义构建步骤的方法来下载缺失的包。看起来可以解决问题，不过我马上发现这个方法对我们也不适用：我们的CI服务器架设在一台内网的PC机上，为了保证网络安全，这台机器的安全策略设置很严格，无法随意从网上下载文件。另一个问题是，我们最近访问NuGet经常出现该死的“连接被重置”错误（你懂的）。这并不是NuGet的错，但是问题的出现也说明NuGet设计思想过于依赖稳定的互联网连接，对项目的构建引入了不稳定的因素。
于是我又回到了原来的路上，那就是在工程下面建一个Lib子目录，把需要引用的第三方库手工加进去。这样保证了签入的文件绝对不会包含我们不需要的东西，也保证了构建不会因为网络问题而中断。
可是，这样不是放弃了NuGet提供的便利的自动更新特性吗？的确是。不过仔细考虑以后，我觉得这并不是一个大问题。仅仅因为NuGet上发布了一个新版本并不意味着我们必须马上引用它；我们还需要检查版本到底更新了什么、有没有提供必须的功能、有没有破坏性的变更，这些都是无法自动完成的。贸然升级版本并不是一个明智的举动。例如，有一个原来的项目还在使用NUnit2.4，虽然NUnit 2.6早已出现了，然而项目里并没有什么必须用到新特性的地方，我们又何必去更新呢？
再见，NuGet。
