这个问题涉及一些其他相关的问题，我只是把每一个问题都扔在上面，随意回答一个或多个。
我问这个问题是因为我有这么多不同类的大解决方案，因为现在我需要分离一些接口，它都分崩离析（循环依赖问题），现在我需要创建多个 DLL，我只想这次一定要以正确的方式进行。
关于论点的范围，这个问题的答案可能很长，我认为首先最好关注什么是 choiches 以及需要在多个程序集中分离项目的原因，一般来说，这可能是一般设计和分层和/或清理项目结构。
1.分离Solutions/DLL有什么好处？
分离解决方案和组件的优势通常与设计方法、代码重用和层组织有关，如上所述，分离解决方案有助于共享对象/组件并在层之间分配责任，促进多目标和可插拔解决方案（参见例如各种存储目标程序集（数据库、文件等））、可测试性
2. 分离Solutions/DLL有什么缺点？
正如其他人在我之前所说的那样，主要缺点首先是复杂性（管理，维护），然后是性能（但这是另一个讨论，说起来并不容易）
3. 如果我为每个可共享的资源创建一个新的解决方案/DLL 会不会有很多解决方案？
这取决于，首先我认为这可能取决于设计选择
4. 在解决方案过多（如 40+）之后，这会对 IDE 性能（VS.NET 2008）产生一些不良影响吗？
我不太确定 VS2008 IDE 中的性能下降，但可以肯定的是，管理 60 多个项目的单个解决方案可能会影响性能，而不是管理 60 个项目的单个解决方案，例如每个有 20 个项目的 4 个解决方案。必须清楚的是，VS IDE 性能可能会下降即使在仅从单个或双项目解决方案中打开例如 35 个文件之后..
最后，我认为我要记住的重要一点是，最好“构建”它真正需要的东西，而不是陷入过度设计，所以当事情变得太复杂而无法管理（对于许多项目）时，它会更好停下来想“一切顺利？”
一般来说，我建议使用至少一个 DLL（将业务逻辑与 UI 分开），如果您的应用程序版本不同，可能不需要所有这些代码，则建议使用更多。
*我们经常让自己相信我们会重用那个美妙的 Order 类。我们可能不会。领域模型只是倾向于不同。
许多 dll 的主要缺点是：
优点是更多的分离 - 但实际上您可以在单个（或几个）dll 中实现相同（或相似）的分离。
关于循环依赖的问题 - 你也许应该看看“依赖注入”和“控制反转”。
一般来说，只要代码中存在逻辑上的依赖关系分离，就应该进行分离。例如，如果您正在构建一套相关的小型应用程序，它们都依赖于一个共同的核心，那么拥有一个包含核心类的库并为每个此类应用程序一个库是有意义的。这是一个反映这种分离的简单依赖图：
+------------> Core <------------+
| ^ |
| | |
Level Builder | Game Server
^ |
| |
+-----------Game Client
最后，.NET 除了通过条件编译外，没有很好的方法来获得纯测试代码依赖项，因此将各种测试放在单独的库中也是一个好主意。
我一直在与您的问题相反 - 太多的 dll 和依赖项。
我不知道答案，但这里有一些问题可能会给你一些有用的指示。
在 C# 中构建大型 winforms 应用程序的项目和依赖项
在 Visual Studio 中卸载项目时，您如何处理引用？
请注意，您可以在同一个 dll 中拥有不同的名称空间（相反，您可以将名称空间分布在多个 dll 上）。
对于我的解决方案-with-lots-of-projects，我目前有一个设置，其中我有一个名为“WorkingSetOnly”的自定义构建配置（单击调试/发布组合并选择配置管理器），我可以在其中选择编译或不编译运行中的每个项目——这使得运行更快，但保留了智能感知、goto 定义等。我还使用解决方案文件夹将项目组织成两个“桶”——WorkingSet 和其他，尽管我还没有找到链接两者的方法（配置和文件夹）自动。
循环依赖问题意味着：
[Lib1]
[Project1]
[ClassA]
[Project2]
[ClassB]
如果 ClassA 和 ClassB 相互引用，则应将它们拉出到 Lib1 并让 Project1 和 Project2 引用 Lib1，因为不这样做很难保持 Project1 和 2 同步。
这并不意味着疯狂，我相信 IDE 性能不会是一个大问题。如果您有 40 多个项目，则存在设计问题。