关于从TFS加载解决方案时缺少dll?

时间:2015-11-24 11:36:06

标签: .net visual-studio dll tfs

我不确定检查员(签入者)和装载程序是否做错了或者TFS有一些功能我不知道哪些有助于检查员检查TFS建议的内容(列为 包含的文件 ),但仍然可以帮助加载程序轻松加载解决方案而无需执行任何其他步骤(例如修复missing-dll问题,使用nuget重新安装缺少的dll, ...)。

目前,如果检查程序检入所有引用的dll,则不会出现问题。然而,这并不是TFS默认建议你的。这对我来说是最难理解的事情。如果没有签入dll(首先使用 将项目添加到文件夹 ),加载解决方案后的加载程序将错过dll。我想要的是当加载器从TFS加载任何解决方案时,他不需要在构建和运行解决方案之前做任何进一步的步骤(非常麻烦,甚至有时不可能轻易解决)。当然,如果当前本地文件夹具有所有必需的dll,则您不会看到问题。问题出现在您第一次加载解决方案时,或者在某个时候切换到新解决方案(使用获取特定版本)并完全覆盖本地。

我希望你明白我的意思。我对TFS很新,所以这个问题困扰着我。如果我是唯一同时扮演检查者和装载者角色的人,我会选择登记dll,但我不确定这是否正确。谢谢你的帮助。

1 个答案:

答案 0 :(得分:3)

这根本不是特定于TFS的。它发生在所有类型的版本控制中,并且在所有人们不小心他们检查的可怕项目和解决方案文件的环境中。

规则一:执行检查输出程序集。规则二:不要引用解决方案根目录之外的项目。规则三: not,ever 引用输出程序集(bin\Debug\Foo.dll)。创建项目引用或创建NuGet包。规则四:使用NuGet进行包管理,并使用私有NuGet服务器作为主服务器或后备服务器,这样您就可以构建Internet或NuGet何时(您的连接)关闭。规则五:如果,如果您必须链接来自不同解决方案的项目,只需从其主页"更新其包裹。解决方案,否则包路径将被弄乱。

这些简单的规则将确保您的项目和解决方案可以在同事之间共享。但是你会惊讶于有多少人做错了,拒绝改变他们的工作方式,积极地伤害他们同事的生产力。

一个非常简单的检查是干净地获取解决方案并尝试编译它。如果您收到参考警告(与编译器错误级联),那么您做错了什么。在文本编辑器中打开.csproj文件。如果有任何地方..\,您就会遇到麻烦。