我们有大约100多个项目的解决方案，其中大多数是C＃。当然，开放和构建需要很长时间，所以我正在寻找这种野兽的最佳实践。我希望得到答案的问题是：
每个项目应该构建到自己的文件夹，还是应该构建到同一个输出文件夹（它们都是同一个应用程序的一部分）
解决方案的文件夹是组织内容的好方法吗？
我知道将解决方案拆分为多个较小的解决方案是一种选择，但是它带有自己的一组重构和构建头痛，所以我们可以将它保存为一个单独的线程： - ）
答案 0 :(得分：41)
您可能对我撰写的这两篇MSBuild文章感兴趣。
MSBuild: Best Practices For Creating Reliable Builds, Part 1
MSBuild: Best Practices For Creating Reliable Builds, Part 2
特别是在第2部分中，您可能需要查看构建大型源树部分。
尽管在这里简要回答你的问题：
Sayed Ibrahim Hashimi
我的书：Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build
答案 1 :(得分：9)
+1 保留使用解决方案文件夹来帮助整理内容。
项目构建到自己的文件夹的+1。我们最初尝试了一个常见的输出文件夹，这可能导致查找过时参考文件的细微和痛苦。
FWIW，我们使用项目参考解决方案，虽然现在nuget可能是一个更好的选择，但已经发现svn：externals适用于第三方和（框架类型）内部组件。在引用svn：externals时犯了使用特定修订号而不是HEAD的习惯（有罪的是：）
答案 2 :(得分：8)
卸载您不经常使用的项目，并购买SSD。 SSD不会缩短编译时间，但Visual Studio的打开/关闭/构建速度提高了两倍。
答案 3 :(得分：6)
我们有类似的问题，因为我们有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]
答案 4 :(得分：4)
我们在这里开展类似的大型项目。事实证明，解决方案文件夹是组织事物的好方法，我们倾向于将copy local set留给true。每个项目都构建到自己的文件夹，然后我们知道每个可部署的项目都有正确的二进制子集。
至于时间开放和时间建设，如果不打破较小的解决方案，这将很难修复。您可以调查并行化构建（谷歌“并行MS构建”以实现此目的并集成到UI中）以提高速度。另外，查看设计并查看是否重构了一些项目以减少整体可能的帮助。
答案 5 :(得分：3)
在缓解建筑物疼痛方面，您可以使用“Configuration Manager ...”选项进行构建，以启用或禁用特定项目的构建。您可以拥有一个“Project [n] Build”，它可以排除某些项目，并在您定位特定项目时使用它。
就100多个项目而言，我知道你不想在这个关于减少解决方案规模的好处的问题上受到重创，但我认为在加速加载方面没有其他选择devenv的时间（和内存使用情况）。
答案 6 :(得分：3)
我通常对此做些什么取决于“调试”过程实际发生的方式。通常我虽然没有将copy local设置为true。我为每个项目设置了构建目录，以便将所有内容输出到所需的终点。
因此，在每次构建之后，我都有一个填充的文件夹，其中包含所有dll和任何Windows / Web应用程序，并且所有项目都在正确的位置。因为dll最终会在正确的位置结束，所以不需要复制本地。
注意的
以上适用于我的解决方案，通常是Web应用程序，我没有遇到任何引用问题，但它可能是有可能的！
答案 7 :(得分：3)
我们有类似的问题。我们使用更小的解决方案解决它我们有一个打开一切的主解决方案。但是。那很糟糕。因此，我们按开发人员类型细分小型解决方案。因此，DB开发人员有一个解决方案可以加载他们关心的项目，服务开发人员和UI开发人员。当有人必须打开整个解决方案以获得他们日常所需的工作时，这种情况很少见。它不是灵丹妙药 - 它具有上升空间和缺点。请参阅“多解决方案模型”in this article（忽略有关使用VSS的部分：）
答案 8 :(得分：2)
我认为，对于解决方案来说，最好的做法应该是打破它们。您可以将“解决方案”视为将必要项目和其他部分集中在一起解决问题的地方。通过将100多个项目分解为专门为整体问题的一部分开发解决方案的多个解决方案，您可以通过加快与所需项目的交互并简化问题域来在特定时间处理更少的问题。
每个解决方案都会产生它负责的输出。此输出应具有可在自动过程中设置的版本信息。当输出稳定时，您可以使用最新的内部分发更新相关项目和解决方案中的引用。如果您仍想进入代码并访问源代码，您实际上可以使用Microsoft符号服务器执行此操作，Visual Studio可以使用该服务器以允许您进入引用的程序集甚至获取源代码。
同步开发可以通过在等待未完成但又希望开发的依赖项的情况下预先指定接口并模拟正在开发的程序集来完成。
我发现这是一种最佳做法，因为当你以这种方式分解时，整体努力的复杂程度是没有限制的。将所有项目放在一个解决方案中最终会达到上限。
希望这些信息有所帮助。
答案 9 :(得分：2)
我们有大约60多个项目，我们不使用解决方案文件。我们混合使用C＃和VB.Net项目。表演总是一个问题。我们不同时处理所有项目。每个开发人员都根据他们正在处理的项目创建自己的解决方案文件。解决方案文件未检入我们的源代码管理中。
所有类库项目都将构建到源目录根目录下的CommonBin文件夹中。可执行文件/ Web项目构建到其各自的文件夹中。
我们不使用项目引用，而是使用CommonBin文件夹中基于文件的引用。我编写了一个自定义MSBuild任务，它将检查项目并确定构建顺序。
我们已经使用了几年，并且没有抱怨。
答案 10 :(得分：0)
这一切都与您的定义和对解决方案和项目的看法有关。在我看来，解决方案只是一个逻辑分组的项目，解决了一个非常具体的要求。我们开发了一个大型Intranet应用程序。该Intranet中的每个应用程序都有自己的解决方案，也可能包含exes或Windows服务的项目。然后我们有一个集中的框架，包括基类和助手以及httphandlers / httpmodules。基础框架相当大，并且被所有应用程序使用。通过以这种方式拆分许多解决方案，您可以减少解决方案所需的项目数量，因为大多数解决方案彼此无关。
在解决方案中拥有众多项目只是糟糕的设计。没有理由在解决方案下有那么多项目。我看到的另一个问题是项目引用，它们最终会让你失望，特别是如果你想将你的解决方案分成更小的解决方案。
我的建议是这样做并开发一个集中式框架（如果你愿意，你可以自己实现企业库）。您可以通过GAC进行共享，也可以直接引用文件位置，以便拥有中央存储。您也可以对集中式业务对象使用相同的策略。
如果要直接引用DLL，则需要在项目中使用copy local false（在c：\ mycompany \ bin \ mycompany.dll之类的地方）引用它。在运行时，您需要向app.config或web.config添加一些设置，以使其引用不在GAC或运行时bin中的文件。实际上，无论是否本地复制，或者dll是否在bin中，或者甚至在GAC中，都无关紧要，因为配置将覆盖这两者。我认为复制本地并且系统混乱是不好的做法。如果您需要调试其中一个程序集，则很可能必须临时复制本地。
您可以阅读我关于如何在没有GAC的情况下全局使用DLL的文章。我真的不喜欢GAC，主要是因为它阻止了xcopy部署，并且没有触发应用程序的自动重启。
答案 11 :(得分：0)
设置CopyLocal = false将减少构建时间，但在部署期间可能会导致不同的问题。
有许多情况，当您需要将“复制本地”左侧设为“真”时，例如 顶级项目， 二级依赖， 反射调用的DLL。
我设置CopyLocal = false的经验不成功。请参阅我的博文"Do NOT Change "Copy Local” project references to false, unless understand subsequences."
中的赞成和缺点摘要