在 Visual Studio 中卸载项目时，任何引用项目都会在其对已卸载项目的引用上获得警告三角形。我为自己编写了一个宏来做一些聪明的事情（检测项目的添加/删除并将任何引用从文件/项目依赖项转换为文件），但我不敢相信我没有错过更简单的东西。如果我必须手动更改引用（并且它打破了“个人解决方案/共享项目”团队开发范式），卸载功能怎么能有用。
（这个问题与这个关于在 Visual Studio 中构建大型解决方案的问题的答案有关——一些答案提到了有很多项目的解决方案，但是“卸载”未使用的项目以提高性能。）
对于我的项目，我创建了一个assemblies文件夹，项目会自动从设置的位置复制到该文件夹中，其他项目复制构建到该文件夹中。
引用程序集项目的后期构建：
if not exist "C:\builds\Project1" md "C:\builds\Project1\" copy "$(TargetDir)$(TargetName).*" "C:\builds\Project1\"
用于引用项目的预构建：
如果存在 "c:\builds\Project1\" 复制 "c:\builds\Project1*.*" "$(ProjectDir)assemblies"
项目文件指向其assemblies子文件夹以供参考，因此即使从解决方案中卸载源项目，也将使用最后构建的程序集，而不会在开发时将整个项目放在内存中的性能问题。
如果您使用文件引用，那么在同一个解决方案中拥有项目有什么好处？
如果您app.exe使用utils.dll并且更改了代码utils.dll，那么如果它在同一个解决方案中，VS 会注意到依赖关系并重新编译两者。如果它不在解决方案中，您将不得不跳出，utils.dll单独重新编译，然后跳回并重新编译app.exe。
这或多或少变得重要，具体取决于您的 exe 引用了多少其他 dll，以及它们更改的频率（在团队环境中，根据我的经验，共享 dll 的更改经常发生）。
还有一个副作用是，如果您在 VS 中有 100 个项目，则需要很长时间来处理它们，以便确定它们是否需要重新编译。
卸载项目是一项临时操作，因此您可以将实际项目文件编辑为 XML（文本）。如果您想从解决方案中完全删除一个项目，您应该使用“删除”菜单选项，该选项将负责删除对该项目的任何引用。
使用项目引用的一个优点是它允许您轻松地通过代码进行调试。它还自动确保您使用的是正确的配置构建（即，如果您在“调试”模式下构建，它将使用程序集的调试版本）。话虽如此，您对于将选择哪个版本/构建的依赖项目失去了一些确定性 - 项目引用意味着您始终使用最新的。
是的，为了让 Visual Studio 确定构建依赖项，它必须能够查看和构建所有项目，这意味着项目引用。
我刚刚通过 MSDN 文档阅读了有关构建解决方案和项目的灵感。
我没有注意到的是，在多项目解决方案中，解决方案资源管理器中的上下文菜单提出了一个项目依赖项弹出窗口。如果您还没有通过项目之间的项目引用定义它们，您可以在这里手动定义项目依赖关系。
见这里（MSDN 链接，几周后会自毁）