无痛本地开发，同时还引用 NuGet 包 [英] Pain-free local development while also referencing NuGet packages
问题描述
我正在尝试发布和使用类库的版本化 NuGet 包，同时避免本地开发的麻烦.这是一个示例 Visual Studio 解决方案布局:
I am attempting to publish and consume versioned NuGet packages of class libraries while avoiding headaches for local development. Here is a sample Visual Studio solution layout:
| Libraries
| LibraryA
| LibraryB
| LibraryC
| Applications
| ApplicationD
| ApplicationE
这是一个包含共享类库和多个应用程序的单一解决方案.当前，应用程序对类库的引用是本地解决方案内引用.
This is a single solution containing both shared class libraries and multiple applications. Currently references to the class libraries by the applications are local in-solution references.
我想做的是将库(A、B、C)发布为版本控制的 NuGet 包，然后应用程序根据需要(D、E)引用这些包.这允许对共享库的更改独立于对已部署应用程序的更新.否则，更改一个库可能会导致十几个或更多应用程序中的二进制文件发生更改，所有这些在技术上都需要进行测试.这是不可取的，使用 NuGet 进行版本控制可以解决这个问题.
What I would like to do is to publish the libraries (A,B,C) as versioned NuGet packages which are then referenced by the applications as needed (D,E). This allows a change to a shared library to be independent from an update to an application which is deployed. Without this, changing one library could cause the binaries to change in a dozen or more applications, all of which would technically need to be tested. This is undesirable, and versioning with NuGet fixes this.
但是，假设我想同时更新 LibraryA 和 ApplicationD 的内容.为了在我们切换到 NuGet 后执行此操作，我必须对 LibraryA 进行更改、提交它们，等待创建包，告诉 ApplicationD 更新其对 LibraryA 的引用，然后在 ApplicationD 中进行测试或开发.这比使用本地解决方案引用同时使用两者要复杂得多.
However, let us say that I want to update the content of LibraryA and ApplicationD at the same time. In order to do this after we have switched to NuGet, I will have to make changes to LibraryA, commit them, wait for the package to be created, tell ApplicationD to update its reference to LibraryA, and then test or develop in ApplicationD. This is far more complicated than simply working with both at the same time using local in-solution references.
有什么更好的方法既能让我的共享类库获得版本化 NuGet 包的健壮性，又能让开发变得简单，即使它跨越多个项目和应用程序?我发现的唯一其他解决方案都涉及太多开销或头痛，例如必须不断更改 NuGet 包和本地项目之间对 ApplicationD 的引用.
What is a better way to get both the robustness of versioned NuGet packages for my shared class libraries while also keeping development simple even if it spans over multiple projects and applications? The only other solutions I have found all involve too much overhead or headache, such as having to constantly change the references for ApplicationD between the NuGet package and the local project.
为了澄清前提，这个问题假设如下:
To clarify the premise, this question assumes the following:
- 无法对架构(解决方案和项目组织)进行大量重组
- 共享库将以非平凡的频率发生变化
- 更改共享库不能强制更新任何应用程序
- 应用程序可以引用不同版本的共享库
推荐答案
不幸的是，真的没有办法两全其美.在我的公司内部，我们通过快速构建/部署过程在一定程度上缓解了这种情况，它通过始终引用 NuGet 包来抵消大部分负担.基本上，我们所有的应用程序都使用托管在本地 NuGet 存储库中的同一库的不同版本.由于我们使用自己的软件来构建、部署和托管包，因此可以非常快速地更新库，然后在另一个解决方案中更新其 NuGet 包.基本上，我们发现的最快的工作流程是这样的:
Unfortunately, there really isn't a way to have the best of both worlds. Internally in my company, we've mitigated it somewhat with a fast build/deploy process, which counteracts most of the burdens with always referencing a NuGet package. Basically, all of our applications use a different version of the same library hosted in a local NuGet repository. Since we use our own software to build, deploy, and host the packages, it makes it pretty quick to update the library, then update its NuGet package in another solution. Essentially, the fastest workflow we've found is this:
- 对库进行更改
- 自动构建和部署以 1 递增的库版本并将其部署到内部 NuGet 提要
- 更新消费者应用程序中的 NuGet 包
从签入到更新消费项目的整个过程大约需要 3 分钟.NuGet 存储库还有一个符号/源服务器，可极大地帮助调试.
The whole process from check-in to updating the consuming project takes around 3 minutes. The NuGet repository also has a symbol/source server which helps tremendously with debugging.
这篇关于无痛本地开发，同时还引用 NuGet 包的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
