在设置包含许多项目的Visual Studio .NET解决方案时，您是否觉得“解决方案文件夹”有用？有什么缺点？
我最初的想法是，使用解决方案文件夹对于在解决方案中逻辑组织类似项目非常有用。但是，我很惊讶地发现创建一个解决方案文件夹不会创建相应的Windows文件夹。来自MSDN：
“解决方案文件夹是一个 解决方案中的组织工具 资源管理器;对应的Windows 文件夹未创建。我们推荐 你组织你的项目 磁盘与您组织的方式相同 他们在解决方案中。“
我正在考虑组织解决方案，以便每个项目都包含在解决方案文件夹中。这是个好主意吗？
答案 0 :(得分：15)
解决方案文件夹可以帮助您组织项目。它们有一个很大的优势：如果您想构建一些项目集，那么您可以标记它们并右键单击它们并选择“构建所选项目”。 如果您的解决方案文件夹组织适合您，只需右键单击解决方案文件夹并选择“构建”。
我们有“MainApps”和“Test”（以及其他一些）的sln文件夹。如果您需要所有应用程序，则可构建完整的解决方案。但是，如果您不想等待构建测试项目，只需右键单击并构建“MainApps”文件夹即可！
答案 1 :(得分：12)
解决方案是相关项目的集合，收集在一起以满足某些目的，例如应用程序。解决方案文件（是的，它是一个实际的文件，而不是文件夹，虽然它看起来像VS中的文件夹）本身值得一看 - 它只是描述解决方案包含内容的元数据，最重要的是它的项目。
您可以在不同的解决方案中合理地使用相同的项目。
例如，我们有一个WinForms应用程序，它有以下项目：
构建解决方案构建整个Windows应用程序。
然后我们还有一个Web应用程序 - 在它自己的解决方案中。但是，由于我们重用了我们的几个项目，它们也在Web解决方案中出现，它具有：
同样，构建解决方案会构建整个网站。
我们的项目只在源代码管理中出现一次，而这一切都有效。
我们构建它的方式，解决方案几乎等同于应用程序，尽管这只是一种松散的关系。我们还为Windows应用程序提供了一个部署解决方案，它包含所有WinForms应用程序项目，以及安装项目（创建.MSI）。我们将它分开，因为它包含许多额外的东西，使它非常大。
HTH。
答案 2 :(得分：6)
我们使用解决方案文件夹在解决方案中“关联”项目。例如，我们的大多数“项目”都有3个实际项目 - 实现，单元测试和集成测试。我们将所有3个放在一个解决方案文件夹我们也可能将所有基础设施放在一个和所有CAB模块中。基本上，当您拥有一个包含50多个项目的解决方案时，它有助于保持它们的有序性，这样您就可以只扩展您正在寻找的内容并根据逻辑分组查找内容。
答案 3 :(得分：3)
不，您应该将所有相关的项目放在一个解决方案中。如果您碰巧引用了另一个解决方案并想要访问其源代码，那么您可以将其作为单独的解决方案添加。
答案 4 :(得分：2)
你应该以明智的方式组织。每个项目有一个解决方案文件夹是没有意义的。
我们经常使用的是
- ＆GT; Web（所有Web项目） - ＆GT;数据（任何数据相关项目） - ＆GT;测试（所有单元测试项目）
答案 5 :(得分：2)
根据我的经验，他们只是让事情变得更加混乱，因为MSDN说明了这一点。如果右键单击VS中的实际文件夹，则会显示“在Windows资源管理器中打开文件夹”命令。如果右键单击解决方案文件夹，则不执行任何操作。此外，他们倾向于搞乱破坏解决方案资源管理器的例程;解决方案文件夹中的内容无法正常折叠。
如果您在解决方案中有这么多项目，您觉得需要解决方案文件夹来对其进行排序，请考虑是否可以创建单独的解决方案。
答案 6 :(得分：1)
我不知道解决方案文件夹，但在项目内部，您可以使用文件夹以逻辑方式组织源文件，这些似乎可以很好地传承到文件系统。
答案 7 :(得分：0)
对于正在开发WPF应用程序且设计人员在Expression Blend中访问解决方案的情况，Blend环境中将忽略解决方案文件夹。因此，所有项目仍将显示在顶层。
此外，当Blend加载解决方案时，会显示一个消息框，指出“不支持解决方案文件夹。嵌套项目将正常加载”。可以检查“不再显示此消息”选项，但它仍然有点令人讨厌。
答案 8 :(得分：0)
Here是我前一段时间问过的相关问题。我的一个答案是谈论解决方案文件夹的一些优点/缺点，以及我目前如何使用它们。
答案 9 :(得分：0)
使用解决方案文件夹的一个缺点是它们在您的版本控制系统中的外观。由于解决方案文件夹是逻辑文件夹，因此您无法在VCS中看到它们。相反，您将在一个平面列表中看到所有项目。
这给我带来了困惑，因为结构可能看起来不同，特别是如果你的解决方案文件夹中有文件而不仅仅是项目。