會有這樣一種情況：在同一個解決方案下面，類庫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文件，一條命令行打包自帶依賴關系，同時也方便調試和單步跟蹤，也不破壞項目之間的引入關系。（推薦使用這個），這一步還有一個關鍵點：有了packages.config文件之后，一定要把全部包含在配置文件的包全部下載完之后，即包都在packages文件夾中這個辦法才生效。
注意：
這里的nuget官網是：http://nuget.org，如果你有內部服務器也可以是自動的內部服務器，內部服務器對於第2部的symbols的調試也是可以的，但不推薦用symbols的形式去調試公共庫，業務項目就推薦用symbols。