无痛本地开发，同时还引用了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屋！
