logo标签列表

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

.netvisual-studio-2008
11

在设置拥有多个项目的Visual Studio .NET解决方案时，您是否认为“解决方案文件夹”很有用？它有哪些缺点？

我的初步想法是，在解决方案中使用解决方案文件夹可以很好地逻辑组织相似的项目。但是，我惊讶地发现创建解决方案文件夹并不会创建相应的Windows文件夹。据MSDN（微软开发者网络）所述：

“解决方案文件夹是解决方案资源管理器中的一种组织工具；不会创建相应的 Windows 文件夹。我们建议您在磁盘上以与在解决方案中组织项目的方式相同的方式组织项目。”

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

每个项目都在自己的解决方案文件夹中？那有什么好处呢？或者你是想将项目分组放在几个不同的解决方案文件夹中？ - mhenry1384
后者。我并不是指每个项目都有自己的解决方案文件夹。我的意思是每个项目都包含在一个父级解决方案文件夹中（可能与其他项目一起组织）。 - YeahStu
我动态地使用解决方案文件夹，这意味着我可以在“工作”文件夹中交换项目，从而只需快速重建必要的项目。 - Benjol
这是不使用解决方案文件夹的一个缺点：https://dev59.com/2EXRa4cB1Zd3GeqPucf_ - Benjol
10个回答
15

解决方案文件夹可以帮助组织您的项目。它们有一个很大的优点：如果您想构建一些项目集，那么您可以标记它们，右键单击它们，然后选择“生成选定的项目”。 如果您的解决方案文件夹组织方式合适，您可以简单地右键单击一个解决方案文件夹并选择“生成”。

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

3
我已经使用解决方案文件夹很久了，从没注意到我可以通过右键单击文件夹来构建！+1 - Benjol
12
一个解决方案是相关项目的集合，在一起以满足某个目的，例如一个应用程序。解决方案文件（是实际的文件，而不是文件夹，尽管在Visual Studio中看起来像文件夹）本身值得一看——它只是描述解决方案包含的内容，最重要的是它的项目的元数据。
您可以合法地在不同的解决方案中使用相同的项目。
例如，我们有一个WinForms应用程序，其中包括以下项目：
- BusinessObjects - DataAccess - EnvironmentSupport - CustomControls - MainUI（实际上不叫这个名字，但这就是它的作用）
构建该解决方案会构建整个Windows应用程序。
然后我们还有一个Web应用程序——它有自己的解决方案。但由于我们重用了几个项目，它们也出现在Web解决方案中，该解决方案包含：
- BusinessObjects - DataAccess - EnvironmentSupport - MainWebUI（同样，它实际上不叫这个名字） - CustomWebControls
同样，构建该解决方案会构建整个网站。
我们的项目只出现在源代码控制中一次，一切运作良好。
我们结构化的方式使解决方案几乎等同于一个应用程序，尽管这只是一种松散的关系。我们还为Windows应用程序拥有一个部署解决方案，其中包含所有WinForms应用程序项目以及设置项目（创建.MSI文件）。我们将其保持独立，因为它包含了很多额外的东西，使其相当大。
希望这对您有所帮助。
这是一个很好的、信息丰富的回答……但它与所问的问题没有太多关系。 - Ryan Lundy
5
这段话的意思是：它的目的是“你认为‘解决方案文件夹’有用吗？”我认为我的回答与此相关。我们使用解决方案没有任何缺点，因此没有评论。通过注意到解决方案实际上是项目组，也应该清楚将每个项目放在自己的文件夹中不是一个好主意。 - ChrisA
另外，重新阅读原帖的问题，他可能并不是指每个项目都在单独的解决方案中，而只是在一个解决方案中。如果这些项目以某种方式彼此相关，则这是明智的做法。 - ChrisA
@ChrisA 顺便问一下，你的UI项目文件夹实际上叫什么？只是好奇问一下。 - Soham Dasgupta
@Soham：通常我们的解决方案只有一个主UI项目，所以它将被命名为应用程序的名称。 - ChrisA
6
我们经常使用解决方案文件夹来“关联”解决方案中的项目。例如，我们的大多数“项目”实际上有3个项目——实现、单元测试和集成测试。我们将这三个项目放在一个解决方案文件夹中。我们还可能将所有基础设施放在一个文件夹中，将所有CAB模块放在另一个文件夹中。当你有一个包含50多个项目的解决方案时，它有助于保持它们的组织，这样你就可以只展开你正在查找的内容，并根据逻辑分组查找。
3
不，你应该把所有相关的项目放在一个解决方案中。如果你需要引用另一个解决方案并想要访问其源代码，则将其作为单独的解决方案添加。
3

根据MSDN的说明，我的经验是它们只会让事情变得更加混乱。如果在VS中右键单击一个真正的文件夹，您会得到“在Windows资源管理器中打开文件夹”命令。如果右键单击解决方案文件夹，则没有任何反应。此外，它们往往会破坏折叠解决方案资源管理器的例程；解决方案文件夹中的内容无法正确折叠。

如果您在一个解决方案中有很多项目需要整理，可以考虑是否可以创建单独的解决方案来代替使用解决方案文件夹。

2

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

我们经常使用以下方式

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

1
我不太了解“解决方案文件夹”，但在项目内部，您可以使用文件夹以逻辑方式组织源文件，并且这些文件夹似乎可以很好地映射到文件系统上。
2
我觉得我所掌握的信息与问题的总体讨论相关，即使不是确切的问题。/耸耸肩 - GWLlosa
不，我认为这里有一个有效的观点（虽然表述不好）：为什么解决方案文件夹的行为应该与项目文件夹如此不同呢？肯定保持一致会更好（或者至少不那么令人困惑）。这可能归结于一个事实，即项目可以在不同的解决方案中重复使用，每个解决方案可能具有不同的基本目录，因此它们相对的“解决方案文件夹”在每种情况下都必须不同。但这对我来说似乎并不难。 - piers7
0

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

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

0

这里是我之前提出的一个相关问题。其中一个我的回答谈到了解决方案文件夹的一些优缺点，以及我目前如何使用它们。

0
使用解决方案文件夹的一个缺点是它们在版本控制系统中的外观。由于解决方案文件夹是逻辑文件夹，因此您在VCS中看不到它们。相反，您将在一个平面列表中看到所有项目。
这使我感到困惑，因为结构可能看起来非常不同，特别是如果您的解决方案文件夹中有文件而不仅仅是项目。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接