问：是否有可能/可行，将多个解决方案存储在一个“解决方案”目录中，并将多个 NuGet 包存储在另一个“包”目录中，并且所有内容都可以在不同版本中很好地工作？
更多详细信息...
例如：我有 2 个项目。ProjectA 需要 Newstonsoft.Json.4.5.11，ProjectB 需要 Newstonsoft.Json.5.0.6。
例如，我对两者都有一个解决方案文件。我需要我所有的解决方案文件在同一个目录中（这只是遵循的过程，一个目录中的所有解决方案都是依次构建的）。
默认情况下，NuGet 将packages在每个解决方案文件旁边创建一个目录。
我创建了一个nuget.config文件，允许我将包存储在一个名为“SharedPackages”的单个目录中，遵循以下答案：Nu-Get & issue with project level dependency for projects referenced by multiple solutions
<settings>
<repositoryPath>..\SharedPackages</repositoryPath>
</settings>
到目前为止效果很好，所以我的结构是：
\Projects\ProjectA
\Projects\ProjectB
\Solutions
\SharedPackages
如果我创建 ProjectB，默认情况下它具有 Json.NET 4.5.11。如果我去Manage NuGet Packages for Solution我可以选择将其更新到版本 5.0.6。这很棒，因为 ProjectB 需要更新的版本。更好的是，现在在我Shared Packages的目录中，我有一个同时存放两个 Json.NET 版本的目录，因此 ProjectA 可以使用旧版本。
但是，现在我想将 ProjectC 创建为完整的 MVC4 Web 应用程序。对于 JQuery，在 VS2012 中创建 ASP.NET MVC4 应用程序时，您当前会获得 1.8.2 版本。我也得到了淘汰赛 2.2.0。
我的过程是，我删除默认packages目录，将新解决方案移动到Solutions现有目录旁边的目录nuget.config并编辑新解决方案文件以更新新 .csproj 文件的相对路径。然后，当我构建时，NuGet 包管理器将我需要的额外包（ProjectA 和 ProjectB 未使用）恢复到Shared Packages目录中。但是...我收到构建错误，它无法解析一些引用，包括 DotNetOpenAuth、WebGrease、System.Spatial...这些引用指向packages目录，而不是SharedPackages目录...
顺便说一句：如果我为解决方案启用包还原，则默认情况下它还会尝试将它们还原到目录中的packages文件夹Solutions，而不是将它们还原到SharedPackages目录中。
大约在这一点上，我意识到仅创建nuget.config文件对于 ProjectA 和 ProjectB 也是不够的，尽管它们最初似乎可以正常工作，但 .csproj 中的引用。文件指向bin项目文件下的文件夹，而不是我的SharedPackages目录。
所以我为所有参考手动“查找和替换” ..\packages。..\..\SharedPackages我必须为 ProjectA、ProjectB 和 ProjectC 执行此操作。现在一切都建立起来了，似乎工作正常，新的包进入了正确的位置。
现在，如果我回到 ProjectA，并添加 Knockout 包，这是 2.3.0 版。这与项目 C 使用的另一个 Knockout 包（版本 2.2.0）一起安装得很愉快。这样做还会安装 JQuery 2.0.3 和 JQuery 1.8.2。到目前为止，一切都很好。
作为健全性检查，我创建了另一个 Web 应用程序 - ProjectD，移动文件，更新解决方案和项目中的引用。这一次，一切都是第一次构建。我尝试更新 ProjectD 中的 WebGrease 以查看它是否会保留 ProjectC 的旧版本。这会导致更多问题，而是将其安装到包目录中。WebGrease 似乎也有一个单独的配置设置<WebGreaseLibPath>......它似乎不会恢复......
然后我回到 ProjectB 并尝试“全部更新” - 看起来已经存在的文件已更新SharedPackages，新版本目录与现有目录一起更新，但任何新依赖项（例如，现在我有对 Owin.dll 的引用）放在packages文件夹中:( 如果我删除packages文件夹和binProjectB 中的文件夹，然后构建 ProjectB 解决方案，可以理解的是我得到构建错误，包SharedPackages在任何时候都不会自动恢复到目录。
甚至可以将 NuGet 设置为更新公共目录中的包，而不是packages与解决方案一起更新？
packages使用默认文件夹会更容易，而不是SharedPackages，还是我仍然有问题？
这变成了太多的问题。为了尝试将其保持在范围内，是否有人尝试过类似的设置，他们克服了哪些障碍以及他们是如何管理它的，或者他们是否完全放弃了？如果您放弃了，您是如何最终使用 NuGet 来管理庞大代码库中的包的？
我很欣赏这与这个问题很接近，这个问题已经得到了很好的回答，但是这里的用例略有不同：NuGet 和多种解决方案。它也与这个问题几乎相同：当某些项目包含在多个解决方案中时，为所有解决方案设置一个通用的 nuget 包文件夹，但我还是决定添加这个，因为该问题更侧重于为不同的解决方案提供不同的配置解决方案，而在这里我希望将所有软件包放在一个地方，我只想实现它，看看是否可行。此外，我认为故障排除和研究时间可能对某人有用。