NuGet 和多种解决方案 [英] NuGet and multiple solutions

问题描述

我们有两个解决方案:foo.sln 和 bar.sln

We have two solutions: foo.sln and bar.sln

我有一个 foo 和 bar 都使用的公共库.两者都使用 Common.csproj.

I have a common library that is used by both foo and bar. Common.csproj is used by both.

如果我打开 foo 并更新 nuget 引用，Common.csproj 中的所有引用都指向 foo/packages/.如果我稍后打开 bar 并更新 nuget 引用，则所有引用都将设置为 bar/packages/中的引用.自然，这会激怒 foo 团队，因为它可能导致 Common.csproj 和 Foo 特定的东西(如 Foo.Data.csproj 仍然指向 foo/packages)之间的不兼容.

If I open foo and update nuget references, all references in Common.csproj point to foo/packages/. If I later open bar and update nuget references, all references get set to those in bar/packages/. Naturally, this pisses off the foo team as it can cause incompatibilities between Common.csproj and Foo-specific stuff like Foo.Data.csproj, which still points to foo/packages.

除了:创建一个包含您所有项目的巨大解决方案，如果您需要接触 nuget，只能从该解决方案中执行." 必须有一些明显的解决方案.

There must be some obvious solution other than: "create a huge solution that contains all your projects, and if you need to touch nuget, only do it from that solution."

似乎有一个关于codeplex的问题，(顺便说一句，投票最高的问题)，但显然我太厚了，无法理解这个问题是如何解决的.有人可以解释如何解决这个问题吗?

There seems to be an issue on codeplex, (the top voted issue, incidentally), but evidently I'm too thick to understand how this issue is resolved. Can someone explain how to fix this?

推荐答案

此问题出现在 NuGet 之前.如果您在两个解决方案中引用了一个项目，并且在一个解决方案中打开该项目时更改了该项目中的程序集引用，则当然它会在另一个解决方案中打开该项目时更改该项目的引用路径.无论引用如何更改(使用 NuGet 或其他方式)，情况始终如此.

This problem preceeds NuGet. If you have a project referenced in two solutions, and change assembly references in the project when it is open in one solution, of course it will change the reference path for that project when it is open in the other solution. This has always been the case, regardless of how the reference was changed (with NuGet or otherwise).

但真正的问题是，当您进行更新时，更新的包不会出现在 foo/packages 目录中，对吗?

But the real problem is that when you do an update, the updated packages do not appear in the foo/packages directory right?

简单的解决方案是将 Common.csproj 移动到它自己的解决方案中，具有自己的引用、包文件夹、构建和发布过程.然后创建一个您自己的 NuGet 包，其中内置了任何相关的依赖项.然后，您可以将 Common 包安装到 Foo 和 Bar 中，然后 Foo 团队可以在准备就绪时免费更新到最新版本的 Common.

The simple solution is to move Common.csproj into a solution of its own, with its own references, packages folder, build and release process. Then create a NuGet package of your own with any relevant dependencies built into it. Then you can install your Common package into both Foo and Bar and then the Foo team is free to update to the latest version of Common as and when they are ready.

我听到的反对这一点的主要论点是，您可能希望在调试时单步执行通用代码，但这不再是 Visual Studio 2010 的问题.

The main argument that I have heard against this is that you might want to step through the Common code while debugging, but this is no longer an issue with Visual Studio 2010.

您需要问的基本问题是谁拥有 Common.csproj?是Foo团队还是Bar团队?

The fundamental question you need to ask is who owns Common.csproj? Is it the Foo team or the Bar team?

这篇关于NuGet 和多种解决方案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！