使用Nuget库进行开发和调试

Question

我们已选择使用nuget来管理私有（.NET）库，但已经对DLL进行版本控制变得令人厌烦。

我们假设我们在两个项目中有以下共享库：

• Shared_DAL
• Shared_Model
• Shared_BLL（取决于Shared_DAL和Shared_Model）
• Shared_Mvc（取决于Shared_BLL和Shared_Model

然后，在每个具体项目中我们都有：

• Project_Model（取决于Shared_Model）
• Project_BLL（取决于Shared_DAL，Shared_Model和Project_Model）
• Project_Mvc（取决于Shared_Model，Shared_BLL，Project_Model和Project_BLL）

我们现在遇到的问题是，在特定项目中测试对Shared_BLL所做的更改非常困难。目前，我们必须：

• 将Shared_BLL构建为nuget包
• 将nuget包部署到私有存储库
• 在包含Project_Mvc和Project_BLL
的解决方案中运行Update-Package Shared_BLL

这非常困难且开销很大。

我们尝试了另一种方法，即临时删除DLL引用并用直接引用修改后的DLL替换它们。但是，您必须撤消对项目的所有更改，这不是特别好。

我在这里遗漏了什么吗？如果您在开发生命周期中使用NuGet，那么如何处理DLL？

更新：对于遇到同样问题的人，我们已经远离nuget，直到将其整理出来，并依赖于将DLL放入特定文件夹，并使用绝对路径在每个项目文件的HintPath中。构建事件会更新已定义目录中的DLL，并且可以调试Shared和Project。

Answer 1

我看到你返回引用普通DLL而不是nuget包，但我决定回答。也许别人会对我对这个话题的看法感兴趣。

最后，我对此进行了大量研究，我发现了一些可用于解决远程nuget参考和本地nuget参考之间切换问题的事实。

可以调用 nuget update 来引用所请求包的最新版本。 所以...例如，你有两个nuget存储库（远程和本地）。本地存储库是普通文件夹。

1. You build Project_Mvc from plain sources and nuget automatic restore downloads
   Shared_BLL-1.0.0 from remote repository where you have your "production builds"
2. You decided to build Shared_BLL locally. As you do it in your IDE it generates
   Shared_BLL.9.99.999.0 package.
3. You call update and rebuild Project_Mvc and voila! Shared_BLL.9.99.999.0 is now
   referenced here.

您写道，这是一个很大的开销......可以通过向VS解决方案添加其他项目来自动完成。例如_UpdatePackages项目（Empty C＃项目模板），它将始终位于解决方案的项目列表之上。另外，这也可以向后完成。当您从本地Feed中删除Shared_BLL.9.99.999.0并调用update时，将使用来自第1点的引用替换引用。

处理此问题的另一种方法是使用ripple。由于一些限制，我无法在我的项目中使用它，但在你的情况下可能没问题。