我的解决方案中有22个项目。我通过构建这些项目并选择创建的dll添加了对少数项目的引用。这是最佳做法还是应该使用项目引用而不是指向dll？
此致 VIX。
答案 0 :(得分：3)
我建议您使用项目引用。如果我没有弄错的话，在这种情况下，你将始终引用实际（不过时）的程序集。
答案 1 :(得分：1)
我不了解最佳做法，但至少要考虑一些要点。
项目参考的优点：
dll引用的优点：
注意：您可能不应该将您所引用的项目保留在同一解决方案中，因为这会导致您在构建时发生的一些混乱。
答案 2 :(得分：1)
除了@platon帖子，我会说不仅仅是总是，但在大多数情况下。
示例：
如果您的项目使用了很多年前由您公司的X开发人员编写的库，并且在几年内有一些更改，如果您的解决方案中有150个项目，则添加这些库的DLL引用而不是项目参考可能是一个非常好的解决方案，如果没有在每个编译，你将去PS上踢足球，并在10分钟后回来。
您的项目使用C ++库，并且您希望能够在VS Express版本中构建解决方案（您也在家工作，您应该将代码传递给没有VS的人，导致它花费很多......等等。添加DLL而不是项目引用
依旧...... ....
我的意思是@platon绝对正确，但并非总是如此。
问候。
答案 3 :(得分：0)
我不得不同意platon使用项目引用。很可能你的解决方案需要很长时间才能编译。我们在项目中做了一些事情：
答案 4 :(得分：0)
使用项目引用可以让您在需要时轻松读取代码，插入和调试/编辑这些项目。在我看来，这是非常宝贵的，而不是值得克服的。
但是，如果您因为大量项目而发现构建时间受到影响，则可以采取一些不同的方法。这里有几个：
在Debug配置中，转到解决方案配置管理器并关闭某些项目的“Build”设置。请注意，这会产生副作用，要求您在进行更改时手动构建这些项目，并且在从源代码管理中新下载解决方案时，您必须手动构建这些项目。这种方法适用于“稳定但在开发中”的项目。
预编译项目（在发布配置中）并将它们构建到解决方案根目录下的all文件夹中（类似“ExternalAssemblies”或“References”）。然后，您应该删除这些项目，并通过浏览到编译文件夹并从那里添加引用来重新添加对它们的所有引用。这种方法适用于您不太可能编辑的“稳定”项目。
保持项目不变，并获得更好的PC。更快的磁盘和更多的RAM永远不会在开发人员机器上误入歧途......这种方法的优点应该足够明显。