使用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. 您从普通源构建 Project_Mvc，并从拥有“生产版本”的远程存储库自动恢复下载Shared_BLL-1.0.0
2. 您决定在本地构建 Shared_BLL。当您在 IDE 中执行此操作时，它会生成
   Shared_BLL.9.99.999.0 包。
3. 调用更新并重建 Project_Mvc，瞧！Shared_BLL.9.99.999.0 现在是
   参考这里。

您写道，这是很大的开销...可以通过向 VS 解决方案添加其他项目来自动完成。例如，_UpdatePackages 项目（空 C# 项目模板）将始终位于解决方案项目列表的顶部。此外，这也可以向后完成。当您从本地源删除 Shared_BLL.9.99.999.0 并调用更新时，引用将替换为第 1 点中的引用。

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