我们有一个解决方案，涉及大约100多个项目，其中大多数是C＃。自然，打开和构建都需要很长时间，因此我正在寻找此类野兽的最佳实践。我希望得到的答案是：
应该将每个项目都构建到其自己的文件夹，还是应该将它们都构建到相同的输出文件夹（它们都属于同一应用程序）
解决方案的文件夹是整理资料的好方法吗？
我知道将解决方案分为多个较小的解决方案是一种选择，但这带有其自身的一系列重构和令人头疼的问题，因此也许我们可以将其保存在单独的线程中:-)
Answers:
您可能对我写的这两篇MSBuild文章感兴趣。
特别是在第2部分中，您可能要看一下“构建大型源代码树”一节。
要在这里简要回答您的问题：
易卜拉欣·哈希米说
我的书：在Microsoft Build Engine中：使用MSBuild和Team Foundation Build
+1备用使用解决方案文件夹来帮助组织内容。
+1用于将项目构建到其自己的文件夹。最初，我们尝试了一个常见的输出文件夹，这可能会导致微妙而痛苦地查找过时的引用。
FWIW，我们使用项目参考作为解决方案，尽管现在nuget可能是一个更好的选择，但发现svn：externals对于第3方和（框架类型）内部组装均适用。引用svn：externals时，要养成使用特定版本号而不是HEAD的习惯（有罪的：）
卸载不常用的项目，然后购买SSD。SSD不能改善编译时间，但是Visual Studio的打开/关闭/构建速度快两倍。
我们有类似的问题，因为我们有109个单独的项目要处理。根据我们的经验回答原始问题：
1.您如何最好地处理项目之间的引用
我们使用“添加参考”上下文菜单选项。如果选择“项目”，则默认情况下将依赖项添加到我们的单个全局解决方案文件中。
2.应该打开还是关闭“本地复制”？
根据我们的经验。额外的复制只会增加构建时间。
3.应该将每个项目都构建到其自己的文件夹，还是将它们都构建到相同的输出文件夹（它们都属于同一应用程序）
我们所有的输出都放在一个名为“ bin”的文件夹中。想法是该文件夹与部署软件时的文件夹相同。这有助于防止开发人员设置与部署设置不同时发生的问题。
4.解决方案文件夹是组织资料的好方法吗？
根据我们的经验，没有。一个人的文件夹结构是另一个噩梦。深度嵌套的文件夹只会增加查找任何内容的时间。我们拥有一个完全平面的结构，但是将我们的项目文件，程序集和名称空间命名为相同的名称。
我们构建项目的方式依赖于单个解决方案文件。即使项目本身没有更改，构建它也需要很长时间。为了解决这个问题，我们通常创建另一个“当前工作集”解决方案文件。我们正在处理的所有项目都将添加到该项目中。虽然我们已经看到的一个问题是，对于不在当前集合中的项目中定义的类型，Intellisense会失败，但是构建时间大大缩短了。
我们的解决方案布局的部分示例：
\bin
OurStuff.SLN
OurStuff.App.Administrator
OurStuff.App.Common
OurStuff.App.Installer.Database
OurStuff.App.MediaPlayer
OurStuff.App.Operator
OurStuff.App.Service.Gateway
OurStuff.App.Service.CollectionStation
OurStuff.App.ServiceLocalLauncher
OurStuff.App.StackTester
OurStuff.Auditing
OurStuff.Data
OurStuff.Database
OurStuff.Database.Constants
OurStuff.Database.ObjectModel
OurStuff.Device
OurStuff.Device.Messaging
OurStuff.Diagnostics
...
[etc]
为了减轻构建的麻烦，您可以对构建使用“ Configuration Manager ...”选项，以启用或禁用特定项目的构建。您可以拥有一个“项目[n]构建”，它可以排除某些项目，并在定位特定项目时使用。
就100多个项目而言，我知道您不希望在缩小解决方案规模的好处这一问题上受挫，但我认为在加快加载时间方面，您别无选择。内存使用率）。
我认为，采用如此庞大的解决方案，最佳实践应该是将其分解。您可以将“解决方案”视为一个地方，它将必要的项目以及其他可能需要解决的问题汇总在一起。通过将100多个项目分解为多个解决方案，这些解决方案专门为整个问题的一部分开发解决方案，通过加快与所需项目的交互并简化问题领域，您可以在给定的时间更少地解决问题。
每个解决方案都会产生它负责的输出。此输出应具有可以在自动化过程中设置的版本信息。输出稳定后，您可以使用最新的内部发行版更新相关项目和解决方案中的引用。如果您仍然想进入代码并访问源代码，则实际上可以使用Microsoft符号服务器执行此操作，Visual Studio可以使用它来使您进入引用的程序集，甚至获取源代码。
通过预先指定接口并在等待不完整但希望针对其开发的依赖项时模拟正在开发的程序集，可以完成同时开发。
我发现这是一种最佳做法，因为以这种方式进行物理分解时，对整个工作量的复杂度没有限制。将所有项目放在一个解决方案中最终将达到上限。
希望这些信息对您有所帮助。
我们有大约60多个项目，并且不使用解决方案文件。我们混合了C＃和VB.Net项目。性能始终是一个问题。我们不会同时处理所有项目。每个开发人员都根据他们正在从事的项目创建自己的解决方案文件。解决方案文件不会检入我们的源代码管理中。
所有类库项目都将构建到源目录根目录下的CommonBin文件夹中。可执行文件/ Web项目将构建到其各自的文件夹中。
我们不使用项目引用，而是使用CommonBin文件夹中基于文件的引用。我编写了一个自定义MSBuild任务，该任务将检查项目并确定构建顺序。
我们已经使用了几年了，没有任何投诉。
所有这些都与您的定义有关，并了解什么是解决方案和项目。在我看来，解决方案就是解决特定需求的逻辑项目组合。我们开发了一个大型的Intranet应用程序。该Intranet中的每个应用程序都有其自己的解决方案，其中可能还包含exe或Windows服务项目。然后，我们有了一个集中式框架，其中包含基类，帮助程序和httphandlers / httpmodules之类的东西。基本框架很大，所有应用程序都使用它。通过以这种方式拆分许多解决方案，可以减少一个解决方案所需的项目数量，因为它们中的大多数彼此无关。
一个解决方案中包含许多项目只是糟糕的设计。一个解决方案下没有太多项目的理由。我看到的另一个问题是项目引用，它们确实可以使您最终陷入困境，尤其是如果您想将解决方案拆分为更小的解决方案时。
我的建议是这样做并开发一个集中式框架（如果需要，您可以自己实施企业库）。您可以GAC共享它，也可以直接引用文件位置，以便拥有一个中央存储。您也可以对集中式业务对象使用相同的策略。
如果要直接引用DLL，则需要在项目中使用复制本地false（例如c：\ mycompany \ bin \ mycompany.dll）进行引用。运行时，您需要向app.config或web.config中添加一些设置，以使其引用不在GAC或运行时bin中的文件。实际上，它是否是本地复制都无关紧要，或者dll是否终止在bin中，甚至不在GAC中都没有关系，因为配置将覆盖这两个变量。我认为复制本地文件和凌乱的系统是一种不好的做法。但是，如果您需要调试到这些程序集之一，则很可能必须临时复制本地。
您可以阅读有关如何在不使用GAC的情况下全局使用DLL的文章。我真的不喜欢GAC，主要是因为它阻止了xcopy部署并且不会触发应用程序的自动重启。
设置CopyLocal = false将减少构建时间，但是在部署期间可能导致其他问题。
在很多情况下，当您需要将“复制本地”保留为True时，例如顶级项目，第二级依赖项，通过反射调用的DLL。
我设置CopyLocal = false的经验并不成功。请参阅我的博客文章“除非理解子序列，否则请勿将“ Copy Local”项目引用更改为false，以了解优缺点摘要。