使用“解决方案文件夹”组织 Visual Studio 解决方案答案

【问题标题】：Organizing a Visual Studio Solution with "Solution Folders"使用“解决方案文件夹”组织 Visual Studio 解决方案
【发布时间】：2009-01-07 19:10:23
【问题描述】：

在设置包含多个项目的 Visual Studio .NET 解决方案时，您觉得“解决方案文件夹”有用吗？有什么缺点？

我最初的想法是，使用解决方案文件夹有助于在解决方案中按逻辑组织类似的项目。但是，我惊讶地发现创建解决方案文件夹不会创建相应的 Windows 文件夹。来自 MSDN：

“解决方案文件夹是解决方案中的组织工具探险家；对应的窗口不创建文件夹。我们推荐你组织你的项目以与您组织相同的方式磁盘他们在解决方案中。”

我正在考虑组织解决方案，以便每个项目都包含在解决方案文件夹中。这是个好主意吗？

【问题讨论】：

每个项目都在自己的解决方案文件夹中？这样做有什么好处？还是您的意思是要将项目分组到几个不同的解决方案文件夹中？
后者。我并不是说每个项目都有自己的解决方案文件夹。我的意思是每个项目都将包含在父解决方案文件夹中（可能与其他项目一起组织）。
我“动态”使用解决方案文件夹，这意味着我将项目进出“工作”文件夹，这意味着我可以只快速重建必要的项目。
这是反对使用解决方案文件夹的一点：stackoverflow.com/questions/291545/…

标签： .net visual-studio-2008

【解决方案1】：

解决方案文件夹有助于组织您的项目。它们有一个很大的优势：如果你想构建一些项目集，那么你可以标记它们并右键单击它们并选择“构建选定的项目”。如果您的解决方案文件夹组织适合您，您只需右键单击解决方案文件夹并选择“构建”。

我们有用于“MainApps”和“Test”（以及其他一些）的 sln 文件夹。如果您需要所有应用程序，则构建完整的解决方案。但是，如果您不想等待测试项目构建，您只需右键单击并构建“MainApps”文件夹！

【讨论】：

我使用解决方案文件夹已有很长时间了，但从未注意到我可以通过右键单击该文件夹来构建！ +1

【解决方案2】：

解决方案是相关项目的集合，它们聚集在一起以满足某些目的，例如应用程序。解决方案文件（是的，它是一个实际文件，而不是文件夹，尽管它在 VS 中看起来像一个文件夹）本身值得一看——它只是描述解决方案包含的内容的元数据，最重要的是它的项目。

您可以在不同的解决方案中完全合法地使用相同的项目。

例如，我们有一个 WinForms 应用程序，它有以下项目：

业务对象
数据访问
环境支持
自定义控件
MainUI（实际上并没有这样称呼它，但就是这样）

构建解决方案构建整个 Windows 应用程序。

然后我们还有一个 Web 应用程序 - 在它自己的解决方案中。但是由于我们重用了我们的几个项目，它们也出现在 Web 解决方案中，它具有：

业务对象
数据访问
环境支持
MainWebUI（同样，它实际上并没有这样称呼）
CustomWebControls

同样，构建解决方案就是构建整个网站。

我们的项目只出现在源代码管理中一次，而且一切都很顺利。

按照我们构建它的方式，解决方案几乎等同于应用程序，尽管这只是一种松散的关系。我们还有一个适用于 windows 应用程序的部署解决方案，其中包含所有 WinForms 应用程序项目，以及安装项目（创建 .MSI）。我们将它分开，因为它包含许多额外的东西，使它变得非常大。

HTH。

【讨论】：

这是一个很好的、内容丰富的答案......但它与所提出的问题没有太大关系。
它的目标是“你觉得‘解决方案文件夹’有用吗？”我认为我的回答与此相关。我们对解决方案的使用没有缺点，因此不予置评。通过注意到解决方案实际上是一组项目，还应该清楚的是，将每个项目放在自己的项目中并不是一个好主意。
...另外，重新阅读OP的问题，他可能并不意味着每个项目都在一个单独的解决方案中，只是在一个解决方案中。如果项目以某种方式属于一起，这将是明智的。
@ChrisA 顺便说一句，您实际上如何称呼您的 UI 项目文件夹？好奇地问。
@Soham：通常我们每个解决方案只有一个主 UI 项目，所以无论应用程序调用什么都会调用它。

【解决方案3】：

我们经常使用解决方案文件夹来“关联”解决方案中的项目。例如，我们的大多数“项目”都有 3 个实际项目——实现、单元测试和集成测试。我们将所有 3 个放在一个解决方案文件夹中。我们也可以将所有基础设施放在一个中，将所有 CAB 模块放在另一个中。基本上，当您有一个包含 50 多个项目的解决方案时，它有助于使它们保持井井有条，这样您就可以只扩展您正在寻找的内容并根据逻辑分组查找内容。

【讨论】：

【解决方案4】：

不，您应该将所有相关项目放在一个解决方案中。如果您碰巧引用了另一个解决方案并希望访问其源代码，那么您可以将其添加为单独的解决方案。

【讨论】：

【解决方案5】：

您应该以合理的方式进行组织。每个项目只有一个解决方案文件夹是没有意义的。

我们经常使用的是这个

-> Web（所有 Web 项目） -> 数据（任何与数据相关的项目） -> 测试（所有单元测试项目）

【讨论】：

【解决方案6】：

根据我的经验，由于 MSDN 所述的原因，它们只会让事情变得更加混乱。如果你在 VS 中右键单击一个真实的文件夹，你会得到“在 Windows 资源管理器中打开文件夹”命令。如果您右键单击解决方案文件夹，则什么也没有。此外，他们往往会弄乱导致解决方案资源管理器崩溃的例程；解决方案文件夹中的内容无法正确折叠。

如果您的解决方案中有很多项目，您觉得需要解决方案文件夹来整理它们，请考虑是否可以改为创建单独的解决方案。

【讨论】：

【解决方案7】：

我不知道解决方案文件夹，但在项目内部，您可以使用文件夹以合乎逻辑的方式将源文件组织在一起，这些似乎可以很好地转移到文件系统中。

【讨论】：

我觉得我确实拥有的信息与问题所讨论的一般问题相关，如果不是确切的问题的话。 /耸肩
不，我认为这里有一个正确的观点（如果说得不好）：为什么解决方案文件夹的行为与项目文件夹如此不同？当然一致性会更好（或至少不那么混乱）。大概这一切都归结为这样一个事实，即项目可以在不同的解决方案中重复使用，每个解决方案可能有不同的基本目录，因此它们的相对“解决方案文件夹”在每种情况下都必须不同。但这对我来说似乎并不难。

【解决方案8】：

对于正在开发的 WPF 应用程序让设计人员访问 Expression Blend 中的解决方案的情况，解决方案文件夹在 Blend 环境中将被忽略。因此，所有项目仍将显示在顶层。

此外，当 Blend 加载解决方案时，会显示一个消息框，说明“不支持解决方案文件夹。嵌套项目将正常加载。”可以选中“不再显示此消息”选项，但这仍然有些麻烦。

【讨论】：

【解决方案9】：

Here 是我不久前问的一个相关问题。我在那里的一个答案谈到了解决方案文件夹的一些优点/缺点，以及我目前如何使用它们。

【讨论】：

【解决方案10】：

使用解决方案文件夹的一个缺点是它们在您的版本控制系统中的外观。由于解决方案文件夹是逻辑文件夹，因此您不会在 VCS 中看到它们。相反，您将在一个平面列表中看到您的所有项目。

这让我感到困惑，因为结构看起来可能完全不同，尤其是当您的解决方案文件夹中有文件而不仅仅是项目时。

【讨论】：