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

我已经看到了很多关于这个主题的不同看法,所以我想是否有一个首选的方法.

有关如何针对相同解决方案的多个解决方案设置Visual Studio项目和解决方案的最佳实践吗？

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

在我职业生涯的某个时间,我已经在1,2和3解决方案中看到过这种情况.这是一个简单的例子; 但是,如果项目数量增长怎么办？是什么时候将它保持在一个或分开？

1> Greg D..：

---

实际上,在MSDN上有一些针对此类设置的准则.我在StackOverflow上对类似问题的回答中写了一个简短的摘要.

2> Mike Hadlow..：

---

我在2007年写了这篇博文.这个建议仍然存在:

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

最重要的是,我应该能够从源代码控制中获取代码,在Visual Studio中打开它,点击F5,一切都应该有效.

3> Brad Bruce..：

---

在特定情况下,解决方案适用于开发人员.项目(C-Sharp的.CSPROJ)是实际编译的地方.

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

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

---

这有助于考虑,但对我来说似乎很奇怪.当然,如果多个开发人员正在使用单个Windows窗体应用程序,他们将希望以相同的方式构建它.我想你可以在源代码管理中拥有多个.sln文件.

---

今年我在TechEd问了一位微软"专家",他基本上同意你在这里说的,他主张不添加.sln文件来源控制,只有.csproj文件.每个开发人员选择适合特定任务的组合.