关于从 TFS 加载解决方案时缺少 DLL？

Question

我不太确定检查器（谁签入）和加载器是否做错了什么，或者 TFS 是否有一些我不知道的功能有助于检查器检查 TFS 建议的内容（列为 包含的文件），但仍然可以帮助加载程序轻松加载解决方案，而无需执行任何其他步骤（例如修复丢失的 DLL 问题，使用 nuget 重新安装丢失的 DLL，...） .

目前，如果检查器检查所有引用的 DLL，则不会出现问题。但是，这不是 TFS 默认建议您的。所以这是最难理解的事情（对我来说）。如果不签入 DLL（首先使用将项目添加到文件夹），加载解决方案后的加载程序将丢失 DLL。我想要的是当加载程序从 TFS 加载任何解决方案时，他不需要在构建和运行解决方案之前执行任何进一步的步骤（非常麻烦，甚至有时无法轻松解决）。当然，如果当前本地文件夹包含所有必需的 DLL，您将不会发现问题。该问题仅在您第一次加载解决方案时出现，或者有时您切换到新的解决方案（使用获取特定版本）并完全覆盖本地。

我对 TFS 还很陌生。如果我是唯一一个同时扮演检查器和加载器角色的人，我会选择签入 DLL，但我不确定这是否正确。

Answer 1

这根本不是 TFS 特定的。它发生在各种版本控制中，并且在人们不注意他们签入的可怕项目和解决方案文件的所有环境中。

规则一：不签入输出程序集。规则二：不要引用解决方案根目录之外的项目。规则三：永远不要引用输出程序集 (bin\Debug\Foo.dll)。进行项目引用或创建 NuGet 包。规则四：使用 NuGet 进行包管理，并使用私有 NuGet 服务器作为主要或备用服务器，以便您可以在 Internet 或 NuGet （您的连接）中断时进行构建。规则五：如果，如果你必须从不同的解决方案链接一个项目，只从它的“家”解决方案更新它的包，否则包路径会混乱。

这些简单的规则将确保您的项目和解决方案可以在同事之间共享。但是你会惊讶于有多少人做错了这件事，并且拒绝改变他们处理推荐人的方式，从而积极地损害他们同事的工作效率。

一个非常简单的检查是对您的解决方案进行干净的获取并尝试编译它。如果您收到参考警告（级联到编译器错误），那么您做错了什么。在文本编辑器中打开您的 .csproj 文件。如果有多个..\，你就有麻烦了。