有没有办法让多个应用程序引用一个具有其他项目引用的全局项目
Is there a way to have multiple applications reference a global project that has other project references
经过大量搜索，我似乎无法找到问题的答案。通常，我发现这意味着它是一种不存在或不正确的方法，但我认为仍然值得在互联网上发布一个答案。
基本上，我们有 4 个应用程序引用了 5 个不同的 "source" 项目。所以场景是，当我们添加第 5 个应用程序时（例如），我们将需要创建对其他 5 个不同项目的项目引用，因为应用程序需要它们的输出。
虽然项目量小，但不难，但引发了我们的思考。如果您可以创建一个项目（可能称为 Libs 或其他项目）并引用该项目中的所有 5 个项目，然后应用程序必须仅引用 Libs 会怎样？这个想法看起来很酷，但我不知道它是否可行，因为当你创建一个项目引用时，它指向 Libs 单一输出 libs.dll.
所以要实际提出一个问题，这可能吗？如果可以，如何实现？目前，让 Libs 引用其他 "source" 项目，然后让应用程序引用 Lib 项目不起作用，因为它说缺少程序集。
并回顾一下它是如何创建的。 5 个源项目位于几个不同的解决方案中，因此这种方法唯一乏味的部分是 "add existing project" 在应用程序解决方案的初始启动时。
我们在我的组织中管理此类事情的方式是为每个共享 "source" 项目制作一个 NuGet 包（例如，在我们的例子中，我们有一个错误日志记录库，一个 XML 实用程序库、定制的 HTTP 客户端等）。这些发布到我们的私人 NuGet 提要 URL（托管在 Azure DevOps 上，但如有必要，您可以只使用标准 Windows 文件共享）供我们的开发人员在他们的应用程序中使用。
与您的方法相比，这有一些明显的优势：
1) 依赖项 - 这似乎与您的问题最相关。如果您从自身构建 NuGet 程序包的项目依赖于任何其他 NuGet 程序包（公开可用的程序包，或来自我们私人提要的其他程序包），那么当有人在他们的项目中安装该程序包时，它会自动安装它所依赖的所有其他程序包。
因此，在您的情况下，您可以创建一个 shell "libs" 包，它本身不提供任何内容，但依赖于所有其他包，导致它们被自动安装。在我们的案例中，我们有几个依赖案例（例如 "base" 错误日志包，它被错误处理模块所依赖，这些模块针对不同的应用程序类型量身定制，例如 MVC、Web API、Windows 服务），效果很好
2) 更新和维护。在您的场景中，如果您对 "source" 项目之一进行重大更改，那么，因为您在 Visual Studio 中声明了直接项目引用，任何引用源项目的项目都必须进行相关更改处理源项目的更新，然后才能 re-compile 它并执行您想要实现的任何功能更改。这可能会很痛苦，而且是一个不合时宜的问题，尤其是在进行重大更新的情况下。但是，如果您安装的是包含该功能的 NuGet 包，则应用程序的开发人员可以选择是否以及何时安装该包的更新版本。
还有其他一些小的好处，我不会详细介绍，但是有一些很好的理由说明为什么现在几乎所有主要的编程语言都提供类似的 "package" 和 "feed" 功能作为管理对外部项目和库的依赖的方法。我觉得你的方法已经过时和天真，导致你描述的问题以及其他刺激的可能性。
经过大量搜索，我似乎无法找到问题的答案。通常，我发现这意味着它是一种不存在或不正确的方法，但我认为仍然值得在互联网上发布一个答案。
基本上，我们有 4 个应用程序引用了 5 个不同的 "source" 项目。所以场景是，当我们添加第 5 个应用程序时（例如），我们将需要创建对其他 5 个不同项目的项目引用，因为应用程序需要它们的输出。
虽然项目量小，但不难，但引发了我们的思考。如果您可以创建一个项目（可能称为 Libs 或其他项目）并引用该项目中的所有 5 个项目，然后应用程序必须仅引用 Libs 会怎样？这个想法看起来很酷，但我不知道它是否可行，因为当你创建一个项目引用时，它指向 Libs 单一输出 libs.dll.
所以要实际提出一个问题，这可能吗？如果可以，如何实现？目前，让 Libs 引用其他 "source" 项目，然后让应用程序引用 Lib 项目不起作用，因为它说缺少程序集。
并回顾一下它是如何创建的。 5 个源项目位于几个不同的解决方案中，因此这种方法唯一乏味的部分是 "add existing project" 在应用程序解决方案的初始启动时。
我们在我的组织中管理此类事情的方式是为每个共享 "source" 项目制作一个 NuGet 包（例如，在我们的例子中，我们有一个错误日志记录库，一个 XML 实用程序库、定制的 HTTP 客户端等）。这些发布到我们的私人 NuGet 提要 URL（托管在 Azure DevOps 上，但如有必要，您可以只使用标准 Windows 文件共享）供我们的开发人员在他们的应用程序中使用。
与您的方法相比，这有一些明显的优势：
1) 依赖项 - 这似乎与您的问题最相关。如果您从自身构建 NuGet 程序包的项目依赖于任何其他 NuGet 程序包（公开可用的程序包，或来自我们私人提要的其他程序包），那么当有人在他们的项目中安装该程序包时，它会自动安装它所依赖的所有其他程序包。
因此，在您的情况下，您可以创建一个 shell "libs" 包，它本身不提供任何内容，但依赖于所有其他包，导致它们被自动安装。在我们的案例中，我们有几个依赖案例（例如 "base" 错误日志包，它被错误处理模块所依赖，这些模块针对不同的应用程序类型量身定制，例如 MVC、Web API、Windows 服务），效果很好
2) 更新和维护。在您的场景中，如果您对 "source" 项目之一进行重大更改，那么，因为您在 Visual Studio 中声明了直接项目引用，任何引用源项目的项目都必须进行相关更改处理源项目的更新，然后才能 re-compile 它并执行您想要实现的任何功能更改。这可能会很痛苦，而且是一个不合时宜的问题，尤其是在进行重大更新的情况下。但是，如果您安装的是包含该功能的 NuGet 包，则应用程序的开发人员可以选择是否以及何时安装该包的更新版本。
还有其他一些小的好处，我不会详细介绍，但是有一些很好的理由说明为什么现在几乎所有主要的编程语言都提供类似的 "package" 和 "feed" 功能作为管理对外部项目和库的依赖的方法。我觉得你的方法已经过时和天真，导致你描述的问题以及其他刺激的可能性。