会有这样一种情况：在同一个解决方案下面，类库A是独立的，类库B是依赖于类库A的；类似这样：
所以在使用类库B时必须引入类库A的东西，这时如果作为nuget包打包发布，有如下的解决思路：
1、在整个解决方案上的引用上全部依托nuget进行引入，比如类库A开发好之后，直接打包发布到官网，然后类库B要依赖类库B的时候，直接用nuget安装类库A；那么这时项目上就会多出packages.config的文件，当我们打包类库B时，用命令行直接打包会带上这些依赖，非常方便的包含进去了。当我们在官网下载类库B安装时，会自动的安装上类库A。但这样的方式也有非常不好的一个特点：就是项目联调时无法断点跟踪成了一种难题（可能存在的几种情况，也是不推荐的：①带上pdb文件。②使用symbols服务器，小类库真没必要），尤其是解决方案上自带了单元测试的项目，也是非常痛苦的！
2、类库B还是同样的老方式引用类库A，那么用nuget打包时就要这样处理，先用spec参数生成nuspec文件，然后编辑里面的文件，加上类库A的引用依赖。这样一来，再使用pack进行打包时也能达到第1种的效果。缺点：多了一个配置文件要进行编辑，也多了一步的命令行操作，对于自动化的批处理操作不太合适。优点：断点跟踪，单元测试断点跟踪一目了然，方便调试。
3、这种是一种投机取巧的方式，项目上还是这样操作：类库B还是同样的老方式引用类库A，类库A编译好并发布到官网上，然后再类库B上新建一个packages.config或者在原有的packages.config文件上加入要引入类库A的ID和版本号。我这里不直接使用nguet的管理器进行安装，而是手动写入到packages.config文件，好处是不会直接引用，关系还是在的，只不过是用pack参数打包时能自动引入类库A的依赖；同时这样的好处也非常明显，不用维护nuspec文件，一条命令行打包自带依赖关系，同时也方便调试和单步跟踪，也不破坏项目之间的引入关系。（推荐使用这个）
注意：
这里的nuget官网是：http://nuget.org，如果你有内部服务器也可以是自动的内部服务器，内部服务器对于第2部的symbols的调试也是可以的，但不推荐用symbols的形式去调试公共库，业务项目就推荐用symbols。