我目前正在从事的项目是由多个团队开发的，每个团队负责项目的不同部分。他们都已经建立了自己的C＃项目和解决方案，其配置设置特定于自己的需求。但是，现在我们需要创建另一个全局解决方案，该解决方案将将所有项目组合到同一输出目录中。
我遇到的问题是，我只找到了一种使所有项目构建到同一输出目录中的一种方法 - 我需要为所有项目修改配置。这就是我们想要避免的。我们希望所有这些项目都不了解此"全球"解决方案。每个团队必须保留仅使用自己的子解决方案工作的可能性。
一种可能的解决方法是为所有"全局"解决方案为所有项目创建一个特殊的配置，但是这可能会造成额外的问题，因为现在您必须不断与该特定团队使用的常规配置设置同步此配置设置。我们要做的最后一件事是花几个小时试图找出为什么仅仅是因为开发人员已经检查了其配置的某些复选框而在全球解决方案下构建时不起作用，但忘了在全球配置中进行。<<<<<<<<<<<<
因此，为了简化，我们需要某种输出目录设置或后构建事件，这些事件只有在从该全局，全包解决方案中构建时才会存在。有什么办法可以实现此目标而不更改项目配置中的某些内容？
更新1
我想我需要提及一些额外的细节：
我们需要这个全局解决方案，以便在安装我们的应用程序时尽可能接近最终用户的收益在将此错误发送给工作的团队之前，请在此部分工作。
这意味着，在全局解决方案下构建时，输出目录层次结构应与安装后的程序文件中的构建相同，因此，例如，如果我们有程序文件/myapplication/addins/addins文件夹，其中包含所有内容Addins由不同团队开发的Addins，我们需要全球解决方案来复制Addins项目的二进制文件，并将其置于输出目录中。
事实是，开发一个addin的团队并不需要知道它是一个addin，并且应该将其放置在该文件夹中，因此他们不能更改其相对输出目录以构建/bin/debug/addins。
这里的关键是团队负责可交付。该可交付的是二进制组的集合。因此，"全球"解决方案...或"使用团队可交付成果的产品"有兴趣确保所有"当前可交付成果"一起工作。也就是说，您可以从协作努力中传递出来。
所以这就提出了一些问题。团队提供他们认为是"发行"的内容。这可能是在构建系统中自动的。如果它构建并且所有测试通过，请发布。
您要寻找的是出版或推广发布的团队。源代码是您到达那里的方式，二进制文件就是结果。每个团队都会控制其认为是发布的二进制文件（这可以由构建系统自动化）。
并不是您所要求的，但我希望这是一个可以得出正确结果的答案。
一种非常简单的方式将是创建解决方案。包括所有项目，并添加一个项目（或更多）来处理全局解决方案构建任务。然后，全球解决方案中的项目应引用他们需要的项目，然后让Visual Studio处理如何从每个项目中获取二进制文件。它们（在正常情况下）将被复制到构建项目的输出文件夹。因此，该项目专门为全球构建任务添加了所有引用项目的副本
另一种方法是创建一个全局MSBUILD脚本，该脚本引用其余的构建脚本。每个项目都是MSBUILD脚本
编辑
从评论中看来有两类项目。一个需要建造的，一个不需要的。
对于那些需要构建参考的人作为汇总项目中的项目，为那些不需要构建的人添加它们作为参考或将DLL添加为资源。
使用以后更改构建操作的属性，并复制到输出目录以复制新
在这两种情况下，您现在都将所有DLL都在输出目录中，然后您可以在汇总项目移动的post build contion 应该在特定文件夹中的dll（即不在输出中文件夹）
可以查看连续集成的实践，以及使用脚本构建的构建服务器的用法。这是一个必不可少的工具，当将应用程序的不同部分作为团队开发时，您的问题很好地说明了原因。
如果您使用版本控制系统，则未提及。我在实践中发现，每个开发人员都维护他/她/他们的团队配置并在机器上本地建立，因为您不检查 *.suo或 *。使用大多数个人配置仅影响单个团队成员。
在完全分开的机器上，从所有存储库中签出相同的代码，并在构建计算机上编译项目（这可以完全自动化）。这样可以维护您的构建服务器独立性。
不必担心它是一种"解决方案"。您可以轻松地构建多个解决方案。
由于输出路径是相对的（并且可能是" bin debug"），它将在您在哪里进行构建。如果您希望在同一输出文件夹中的所有二进制文件，则可以调整每个配置的输出路径以匹配。诸如" .... bin debug"之类的东西（显然，这会影响项目在本地机器上构建的位置，但可能并不重要）。这样，多个项目将构建相同的目标输出。
您还可以在构建服务器上包含一个单独的设置构建，该设置并非在每个开发人员本地计算机上包装最终产品。