原来程序集的引用

一个项目所有功能我们不可能都自己写对吧。这个时代 引用一大片的第三方包  项目源文件几百兆 ，有可能第三方包占了总体积99%。有可能我们自己写的代码不过几十行。想想我们原来的 老时代的 ，如何引用一个第三方的组件,新建项目 项目节点上 右键  添加dll引用：

 然后 在代码里你就可以编写代码，有的还有可能额外的给你加点啥配置文件：

1 static void Main(string[] args)
2 {
3     List<int> ali = new List<int>() { 1, 2, 5, 65, 23 };
4     string serialStr = JsonConvert.SerializeObject(ali);
5     Console.WriteLine(serialStr);
6 }

为什么你知道这样用 因为第三方库官方的使用方式就是这么写的。

新的方式

上面那一套有些跟不上时代了。在python里你都看到 install xxx   ，instal xxx 一句话解决。vs也有 那就是 nuget 。直接打开程序包管理器控制台：

PM> Install-Package Newtonsoft.Json 
正在尝试收集与目标为“.NETFramework,Version=v4.6.1”的项目“ConsoleApp2”有关的包“Newtonsoft.Json.13.0.3”的依赖项信息
收集依赖项信息花费时间 45.89 ms
正在尝试解析程序包“Newtonsoft.Json.13.0.3”的依赖项，DependencyBehavior 为“Lowest”
解析依赖项信息花费时间 0 ms
正在解析操作以安装程序包“Newtonsoft.Json.13.0.3”
已解析操作以安装程序包“Newtonsoft.Json.13.0.3”
从“nuget.org”检索包“Newtonsoft.Json 13.0.3” 
  GET https://www.nuget.org/api/v2/package/Newtonsoft.Json/13.0.3
  OK https://www.nuget.org/api/v2/package/Newtonsoft.Json/13.0.3 1996 毫秒
正在安装 Newtonsoft.Json 13.0.3。
正在将程序包“Newtonsoft.Json.13.0.3”添加到文件夹“C:\Users\真红\Source\Repos\ConsoleApp2\packages”
已将程序包“Newtonsoft.Json.13.0.3”添加到文件夹“C:\Users\真红\Source\Repos\ConsoleApp2\packages”
已将程序包“Newtonsoft.Json.13.0.3”添加到“packages.config”
已将“Newtonsoft.Json 13.0.3”成功安装到 ConsoleApp2
执行 nuget 操作花费时间 7.87 sec
已用时间: 00:00:09.5098825
PM> 

或者直接使用图形化方式选择安装：

在离线环境使用nuget

如果在外网新建项目 然后安装了某些 nuget包 ，你的.sln 文件同级目录会有个packages文件夹，那么整个解决方案直接拷贝到内网  直接就可编译（其实背后本质也是引用dll   然后你nuget安装 就自动帮你完成了，你可以理解为这些依赖关系和配置文件规格等等信息在nuget包里已经定义好了 然后你执行nuget安装时帮你转达完成），没错就是你项目右键 添加引用 选dll文件，只不过nuget帮你完成这一过程。我们可以把packages文件夹 内的组件搜集到一起 供内网新建项目时 其他项目进行引用。首先把packages里的组件搜集到一个统一文件夹。然后工具->nuget包管理器->管理解决方案的nuget程序包。在程序包源那 设置那里加 本地搜集的目录。这时浏览选项卡就可以看到组件列表了。
然后选择像常规方式一样安装到内网新建的项目就可以了。

 安装后会在项目生成 一个packages.config 里面有项目安装了的对应的包的项。

 并不只是添加dll程序集引用 ，对于要在app.config添加一些奇奇怪怪配置项的 ，如果有nuget包 会自动帮你完成。比如sqlite 的provider配置项  。否则的化你需要对那个组件非常了解（有可能组件不止一个dll，有可能有些未知的配置项你手敲不一定敲的对，有可能依赖最低.net版本或者依赖另一个组件等等）

这整个过程无需连外网。

概念总结和注意项

注意我们整个过程：在外网安装并搜集所有的包->拷贝包到离线环境->设置离线环境nuget源为拷贝的路径->像常规一样使用包文件nuget又从本地源安装到项目目录下。 nuget安装完成后 整个工程的状态 就跟你原来添加dll引用 完成后整个工程的状态一样了， 你可以理解为这个时候不存在nuget。nuget安装并没有什么跟原来特别不一样的项目结构更改方式。项目不能编译就是不能编译 不要扯什么nuget 跟nuget 无关。

• 我能把packages包拷到 项目文件夹下 ，然后编辑packages.config 然后编译时他就会自动去找对应的文件进行编译吗？不要形成拷贝nuget包到本地 改配置文件 就能重新编译了的错误概念。这个理解是完全错的。抱歉，编译时不会进行nuget任何操作 不会进行加dll引用这种操作。原先nuge安装了模块的项目 那么引用是自动加好了的，那么整个项目拷到内网 一样可编译。
• 内网唯一能做的 找内网nuget源 安装模块，也不存在什么原来安装了 现在丢失了 需要重新安装的说法。
• nuget不需要所谓服务器的说法：本地你指定个文件夹就可以当作源。   

由此带来的思考

这又是我擅长的环节了，写代码不咋行，扯闲淡讲经布道指点江山一套一套的。为什么？ 我们直接手工点来点去 项目上右键 添加dll引用 ，有什么不好 ，有些人会说 不是挺好的吗？确实 ，不要强行装逼  ，这样没什么不好的 因为手工点来点去显得很low所以就不好吗？

但是为什么又要发展成nuget发展成命令行安装这样？一切都是软件工业技术发展过后人的思维的使然 ：当一个东西大了后自然需要规范化 统一化 自动化。跟其他工业技术一样的，没什么好说的。

当你达到一定经验后 你就会幡然醒悟 ：其实本质不是事情有什么不好 或者什么不能完成。

站在更高维度看代问题的时候 就会明白：核心思想在于统一规范和自动化，命令行可以通过脚本 自动化 连接所有过程，这个对于大型项目 是很重要的。

注意平常我们说的 编译器是编译器 ，开发环境是开发环境 ，构建工具是构建工具，构建工具就是帮你把大型软件从源码生成至用户可用的执行文件，这一切需要统一规范和自动化命令行连接作为支撑。 只不过vs帮你把所有东西搞到一起了。

如果有人跟你这么说这么做 但是又说不出原因 因为大家都这样 那么他在装逼。