我们正在使用SonarQube 5.6.6（LTS）和SonarC＃插件版本6.5.0.3766以及TFS 2017更新2（SonarQube插件v.3.0.2）。
我们反复看到，以前标记为已解决的问题（无法修复）会重新开启。我的问题是：为什么SonarQube会以这种方式表现？
StackOverflow上的许多不同帖子（1，2，3）中也提到了此问题，但没有根本原因或解决方案。链接3还声明使用SonarQube 6.2是一个问题。
我很好奇这是因为我们的配置错误还是SonarQube的集成部分？
如果相关，我们的SonarQube服务器在带有MS SQL后端的Win 2012 R2服务器上运行？
此外，我们正在使用TFVC进行版本控制并通过SCM插件获得指责。如果问题已被标记为已解决（赢得修复），我发现它似乎与新问题一样开放（即没有可用的历史记录）。
示例：一位同事在2015年11月在TFVC中最后一次修改的文件中标记了已解决（不会修复）的问题。但是，今天早上该问题被标记为已打开并分配给开发人员最初签入代码在SonarQube中没有以前处于已解决状态的问题的历史记录。它似乎是新文件中的新问题，而不是已经解决的已知问题？
为了避免与编译C＃解决方案相关的奇怪问题，我们总是在构建之前完全清理工作区。我不知道这有什么要说的吗？我们的构建也在不同的构建机器上执行，因此我不知道这是否会使SonarQube认为我们确实总是在分析新文件？
对同一个SonarQube项目使用不同的构建机器和/或构建定义是否会导致此行为？
我还从日志和报告中看到，SonarQube似乎分析了整个解决方案，而不仅仅是已更改的文件。这使得我们的分析非常耗时，并且完全不适合快速反馈回路。我怀疑漫长的分析期和重新开放的问题是相关的。 分析大约280 KLOC的项目需要大约。 8-10分钟作为服务器上的后台任务。这是后续分析（即不是第一次运行）。
这是否与服务器重新打开上述问题有关？
奇怪的是，泄漏期似乎正常，即我们正确识别正确泄漏期内的问题。我还没有对此进行详细验证，但绝对不是所有旧问题都会在泄漏期内报告为开放状态。我们只看到旧问题重新出现，如果包含它们的文件已被修改 - 这将激活该文件中的所有其他问题（来自先前版本或泄漏期）。
除了TFVC SCM插件和覆盖数据路径之外，我没有在构建期间为SonarQube扫描程序指定任何其他cmdline参数。 我们将VSTEST任务v.2用作otherwise it's not possible to collect code coverage in SonarQube when using TFS 2017 update 2 and VS 2017。
请告知我应提供的任何进一步数据以进一步提供帮助。 谢谢你的帮助！