搜索了很多之后，我似乎无法找到问题的答案。通常，我发现这是一种不存在或不正确的方法，但是我仍然值得在互联网上浮现一个答案。
基本上，我们有4个应用程序引用5个不同的“源”项目。因此，场景是，例如，当我们添加第5个应用程序时，由于该应用程序需要它们的输出，因此我们需要创建对其他5个不同项目的项目引用。
这不是一项艰巨的任务，因为项目数量很少，但这使我们思考。如果您可以创建一个项目（可能称为Libs之类），然后引用该项目中的所有5个项目，然后应用程序必须仅引用Libs，该怎么办？这个想法看起来很酷，但是我不知道它是否会起作用，因为在创建项目引用时，它指向Libs单输出libs.dll。
所以实际上要问一个问题，这可能吗？如果可以，怎么办呢？目前，让Lib引用其他“源”项目，然后让应用程序引用Lib项目，因为它说缺少程序集，因此无法正常工作。
仅介绍其创建方式。这5个源项目驻留在几个不同的解决方案中，因此该方法唯一繁琐的部分是在应用程序解决方案的初始启动时“添加现有项目”。
答案 0 :(得分：2)
我们在组织中管理此类事情的方式是为每个共享的“源”项目制作一个NuGet包（例如，在我们的情况下，我们有一个错误日志记录库，一个XML utils库，一个定制的HTTP客户端） ， 和别的）。这些文件将发布到我们的私有NuGet feed URL（托管在Azure DevOps上，但是如果需要，您可以仅使用标准Windows文件共享），供我们的开发人员在其应用程序中使用。
与您的方法相比，它具有一些明显的优势：
1）依赖关系-这似乎与您的问题最相关。如果您自己构建的NuGet程序包项目依赖于其他任何NuGet程序包（可公开获取的程序包，或我们私有供稿中的其他程序），那么当有人在其项目中安装该程序包时，它将自动安装其依赖的所有其他程序包。
因此，在您的情况下，您可以创建一个外壳“ libs”软件包，该软件包本身不提供任何内容，但对所有其他软件包都有依赖性，从而导致它们自动安装。在我们的案例中，我们有几种依赖关系的情况（例如，“错误处理”模块所依赖的“基本”错误日志记录包，这些错误处理模块是为不同的应用程序类型（例如MVC，Web API，Windows服务）量身定制的），并且效果很好。
2）更新和维护。在您的方案中，如果您对一个“源”项目进行了重大更改，那么，由于您在Visual Studio中声明了直接的项目引用，因此任何引用源的项目都必须进行相关更改以应对更新。到源项目中，然后再重新编译它并执行您要实现的任何功能更改。这可能是一个痛苦，并且是一个不合时宜的问题，尤其是在进行重大更新的情况下。但是，如果改为安装包含该功能的NuGet软件包，则应用程序的开发人员可以选择是否以及何时安装该软件包的更新版本。
我也不会谈及其他一些次要的好处，但是有一些很好的理由说明为什么现在几乎所有主要的编程语言都提供类似的“包”和“提要”功能，作为管理对外部依赖的方式项目和图书馆。我认为您的方法过时且幼稚，从而导致您所描述的问题以及潜在的其他烦恼。