Visual Studio 项目/解决方案结构是否有任何最佳实践？答案

【问题标题】：Is there any best practices for Visual Studio Project/Solution Structure?Visual Studio 项目/解决方案结构是否有任何最佳实践？
【发布时间】：2015-04-03 03:42:41
【问题描述】：

我在这个主题上看到了很多不同的看法，所以我想知道是否有首选的方法。

对于如何针对同一解决方案的多个解决方案设置 Visual Studio 项目和解决方案，是否有任何最佳实践？

例如：假设我有一个需要 Web 应用程序、控制台应用程序和共享业务逻辑库的任务。

在我的职业生涯中，我曾在 1、2 和 3 解决方案中看到过这种情况。这是一个简单的例子；但是，如果项目数量增加怎么办？是否有一条线何时将其保持在一个或将其分开？

【问题讨论】：

标签： visual-studio

【解决方案1】：

确实，MSDN 上有一些此类设置的指南。我在 StackOverflow 上的 answer to a similar question 中写了一个简短的总结。

【讨论】：

【解决方案2】：

我早在 2007 年就在博客上写过这个。建议仍然有效：

http://mikehadlow.blogspot.com/2007/07/how-to-structure-visual-studio.html

最重要的是，我应该能够让您的代码脱离源代码控制，在 Visual Studio 中打开它，按 F5，一切都应该正常工作。

【讨论】：

感谢您写这篇文章；我发现它很有帮助，尤其是这样：“理想情况下，您的团队编写的所有源代码都应该放在一个解决方案文件中，所有项目都使用项目引用进行引用。不这样做是我见过的解决问题的最大单一来源。从来没有对内部程序集使用文件引用！真是头疼”

【解决方案3】：

解决方案适用于特定情况下的开发人员。项目（用于 C-Sharp 的 .CSPROJ）是进行真正编译的地方。

理论上，如果有 4 个不同的项目，那么开发人员可能希望将这些项目的 24 种不同组合组合成解决方案。

如果您将所有内容都保留在项目级别，则无需担心开发人员如何安排他们的 .SLN 文件

【讨论】：

我今年在 TechEd 上询问了一位微软“专家”，他基本上同意你在这里所说的，他主张根本不将 .sln 文件添加到源代码控制中，而只添加 .csproj 文件。每个开发人员都会选择适合特定任务的组合。
这很有帮助，但对我来说似乎很奇怪。当然，如果多个开发人员正在开发一个 Windows 窗体应用程序，他们会希望以相同的方式构建它。我认为，您总是可以在源代码管理中拥有多个 .sln 文件。

【解决方案4】：

您可以有多种解决方案，并且每个解决方案都可以引用它关心的项目。扩展您的示例，您的共享业务逻辑库可能具有相应的单元测试库。这两个项目可以包含在一个解决方案中。同时，您可能有另一个解决方案，其中包含您提到的三个项目，但在这种情况下，单元测试库不包括在内。

【讨论】：

【解决方案5】：

我的解决方案通常包括：

Web 应用程序项目
- 用于基础和通用帮助类的“Common”文件夹
- “包含”文件夹
  - “样式”文件夹
  - “脚本”文件夹
  - “图片”文件夹
- “用户控件”文件夹
Web 服务项目
Web 框架项目
业务层项目
业务框架项目
数据访问项目

【讨论】：

【解决方案6】：

我喜欢在解决方案中包含特定任务的所有项目。因此，根据您提到的示例，我将有一个包含三个项目的解决方案，这些项目属于我被要求做的解决方案。这让所有元素一起完成任务，我发现这简化了包含解决手头任务所需的其他元素。

【讨论】：

我想最好的做法，取决于你觉得最简单的做法