我正在一家公司工作，该公司希望将所有.Net应用程序（Web应用程序，Windows应用程序和控制台应用程序）整合到一个Visual Studio解决方案中。
我正在从开发人员那里寻找经验，他们要么以这种方式构造自己的应用程序，要么在一家从事此工作的公司工作。这是一个好主意吗？
将您的所有应用程序放在一个解决方案中，而不是为每个应用程序使用单独的解决方案，优点/缺点是什么？
带有20多个项目的解决方案的Visual Studio有多快？
具有源代码控制的并发开发的解决方案文件的稳定性如何？
Answers:
最近，我们将公司中几乎所有的源代码迁移到一个解决方案中。
为什么？
最初，我们有数十种解决方案。解决方案中的某些项目重用了另一个项目中的项目，没有人关心使用软件包管理器。在您大幅更改几乎在所有地方使用的项目的那一天，预计在接下来的几天或几周内，整个公司的工作将损失数小时。最糟糕的是，您甚至不知道更改将对什么产生确切影响。
将所有代码合并到一个解决方案中是一种替代方法。目前它运行良好，并且依赖关系现在很容易理解。是否要修改方法，还要跟踪此更改可能在代码库中的任何地方产生的影响？Visual Studio可以轻松做到这一点。对我来说，这是成功的。
持续集成现在也变得更加容易。一种编译和部署的解决方案。几乎没有什么可配置的。
它可扩展吗？
在性能方面，Visual Studio使我感到非常惊讶。我认为它将开始提出一个包含50个项目的解决方案。今天，有200多个项目。Visual Studio似乎具有足够的可伸缩性来管理它们，就好像它们只有20个一样。是的，有些事情需要时间。如果您重新编译每个项目，并且具有代码合同，默认情况下启用了代码分析等，则可能需要一段时间。但是没有人期望编译200个项目像10个一样快，而且顺便说一句，您不应该：这是Continuous Integration Server的角色。启动时间（冷启动，然后加载解决方案）非常快；也许没有10个项目的速度快，但是仍然可以接受（在五年多以前购买的机器上，不到20秒）。
更进一步，系统地卸载项目是一个好主意（当将项目组织在解决方案中的目录中时，这确实很容易）。如果某人从事仅需要加载三个项目的工作，则无需加载所有200个项目（当然，除非依赖关系可能受到影响）。
版本控制也可以按预期工作（如果重要，我正在使用SVN服务器）。我没有在真正的并发环境中工作，例如，数十名开发人员经常提交代码，但是我可以想象这不会有太多问题。只是要注意许多开发人员同时添加新项目的情况：合并.sln文件不是最容易的事情。
结论
如果我不得不再次做出决定：
我仍然会将所有内容迁移到一个解决方案中。这极大地减少了破坏依赖关系的痛苦，仅此一项好处就完全值得。将所有代码集中放置也是一个好主意。例如，这使得在Visual Studio中搜索内容成为可能。我还可以处理两个弱相关的项目，但仍然只打开了一个Visual Studio窗口。
我还将研究更多的NuGet以及托管私有NuGet服务器的能力。当您不想将几个项目合并到通用解决方案中时，通过NuGet管理依赖项可以解决一些问题。就个人而言，我没有这种情况，但我想其他公司可能会有。
最后，为每个开发人员投资SSD都可以带来很大的不同。但是您不需要，在我的情况下，代码库仍存储在普通硬盘上。
这是预期的用法。
将您的所有应用程序放在一个解决方案中，而不是为每个应用程序使用单独的解决方案，优点/缺点是什么？
带有20多个项目的解决方案的Visual Studio有多快？
拥有20多个项目……可能还不错。我在没有VS问题的情况下看到了更多内容。非常稳定/快速。但是...如果有问题，可以缓解：在VS中打开.csproj，然后从那里开始工作。您无法获得将所有功能都集成在一个解决方案中的好处，但是您始终可以在需要时重新打开sln，并在需要时仅使用.csproj进行操作（就像您现在所做的那样）。
具有源代码控制的并发开发的解决方案文件的稳定性如何？
解决方案文件仅在您添加/删除项目或解决方案级别的对象时更改，因此很少更改。它是xml，因此您可以查看其中的内容。他们很少改变。