当我们使用微服务架构之后，紧接而来的问题便是服务之间的程序集引用问题，可能没接触过的同学不太理解这句话，都已经微服务化了为什么还要互相引用程序集，当然可以不引用。但是我们会有这样一种情况，我们的每个接口都会有请求参数和返回结果，规范来说我们需要为每个接口分别创建一个请求类（Request）和返回类（Response）。当其他服务或者程序需要调用这个接口传递参数和得到返回结果的时候，最方便的方式就是直接使用服务的程序集，而不是两边同时创建Request和RResponse。同时我们还需要对程序集进行版本控制，而且高本版需要兼容低版本。通过NuGet来进行程序集的使用和版本控制是一件百利而无一害的事，我现在所在的公司便是使用这种方式。

这里说一下我被dll版本坑哭的经历，同时也为现在到处拷贝dll的同学做个提示。我现在的公司架构是从三层改造到微服务的，所以在Web端依然存在着部分三层代码，不同项目之间进行的程序集使用是通过拷贝dll的形式（这里有两个三层项目，还没有完全服务化），A项目中使用了某个服务的程序集，B项目中也使用了该服务的程序集，此时把A项目类库的dll拷贝到B项目中，如果两个相同服务的程序集版本不一致，恭喜你，等着报错吧兄弟（想到这里我就要哭了，第一次不知道被坑惨了，补了一晚上的数据）  ！！当然你可能会说难道你拷贝完都不测试的吗，我们自己的开发组现在有40多个服务，同时还引用了其它组的服务，当时那个项目里有十七八个服务的程序集，一堆人开发，一方面我当时不知道这个坑，另一方面我也没去看代码提交记录谁升级了某个服务的版本，结果发布还没2分钟，大量日志报警袭来:xxx程序集版本未找到！！唉，当晚补数据到凌晨2点，所以，对于程序集的使用，进行规范化的管理是非常有必要的，更重要的是不要拷贝dll！！！

我们这次使用Docker搭建一个自己的NuGet服务器（因为Docker实在太简单了，我已经懒到无可救药了）：

docker run -d -p 8090:80 -v $PWD/nuget/db:/var/www/db -v $PWD/nuget/packages:/var/www/packagefiles -e NUGET_API_KEY=ee28314c-f7fe-2550-bd77-e09eda3d0119 sunside/simple-nuget-server

这里环境变量NUGET_API_KEY要记住后面的命令需要使用

成功后如下图所示：

使用cmd命令到项目文件夹下，执行 dotnet pack 命令：

下载Nuget.exe （下载地址https://dist.nuget.org/win-x86-commandline/v4.7.0/nuget.exe）

将Nuget.exe 放置 C:\Program Files\dotnet目录下（一般安装了netcoreSDK 一定有这个目录）

 

cmd到项目Debug文件夹下，会看到生成的项目包，执行如下命令：

nuget push -Source http://47.99.92.76:8090/ -ApiKey ee28314c-f7fe-2550-bd77-e09eda3d0119 MI.Untity.1.0.0.nupkg （这里的ApiKey则是第一步的环境变量详细参数查看https://docs.microsoft.com/zh-cn/nuget/tools/cli-ref-push）

项目里配置包地址，然后就可以使用了！