TFS自动签出解决方案sln或者项目文件csproj的解决办法

问题：

最近公司一个项目组的源代码解决方案打开时总是出现解决方案或者部分项目被自动签出的情况，但签入又提示没有变更。事情虽 小，导致几个程序员要用项目文件时总是要找其他人签入。浪费不少时间。出现时间有几个月了，也一直没有重视去解决。但最近出现源代码部分被覆盖等一些异常 情况后，问题就变得很严重了，于是决心解决。

分析：

按照解决问题的习惯（这个习惯有时候真的不好），第一反应就是去网上搜索“TFS自动签出解决方案”，“TFS自动签出 sln”，“TFS Auto Check out sln”等关键词，找到两个比较有价值的文章，但还是没有解决问题，一时陷入了困境，解决方案的自动签入前后的文件都是一致的。无奈，干脆放下，出去办公 室透透气，发现查找问题过程中的一个大漏洞，总是一直在分析解决方案，没有去分析也会自动签出的项目文件，回来分析一看，果然找到问题，问题如下图：项目引用的项目文件前后两个版本中Tools项目的相对路径不一致,一个三级，一个两级

根据TFS历史记录找到相应同事的电脑，发现果然是这样，其中一个项目的相对路径关系跟其他人不一样，对比如下

Tools项目：

其他项目：

其他人这两个项目都是放在同一个文件夹下，但他的不一样，就导致相对路径不一致。

附录：搜到的两个网上文章

Automatic Checkout on Build Solution

When I open a solution VS2010 tries to check out SLN file – why?

解决：

将他的本地源代码相对路径（是相对路径，不是绝对路径）修改后跟大家一样的解决了。

本地映射路径修改办法如下，记录备忘下（这个修改每次都要想一下，才记得在哪里改的）：

修改入口：,进去后点击编辑工作区，一看就知道怎么改了

PS：但改了后又碰到一个问题，项目路径还是在加载旧的项目文件路径，解决办法是强制更新解决方案文件,不知道是因为缓存还是其他什么原因导致非要这样操作

如何避免：

源代码的对应程序员各自的物理路径不要求，但各个解决方案，项目文件所在的相对路径必须要一致，否则就可能出现这样的问题。

后记，感悟：

1、查找问题原因时不能一味盲从网上的解决办法，因为情况很多，别人不一定碰到。还是需要冷静自己的分析问题，尤其是在尝试网上解决办法无效的情况下

2、又验证了一直以来的一个经验，很奇怪的问题或者感觉无从下手的问题，很多时候原因都很简单，甚至很低级的。