Проблема
Итак, мы столкнулись с очень странной проблемой. В настоящее время это наша ситуация. У нас есть два сервера сборки, подключенные к двум коллекциям TFS.
- Коллекция A имеет сервер сборки с установленной на нем Windows Server 2012 R2.
- Коллекция B имеет сервер сборки с установленной на нем Windows Server 2008 R2.
На обоих серверах установлен sonar-msbuild-runner. На Коллекции А все работает нормально, но при выполнении анализа на сервере сборки на Коллекции Б мы получаем следующую ошибку.
Faulting application name: SonarQube.MSBuild.PostProcessor.exe, version: .9.0.0, time stamp: 0x559d2baa
Faulting module name: clr.dll, version: 4.0.30319.34209, time stamp: 0x5348961e
Exception code: 0xc0000005
Fault offset: 0x00002d1f
Faulting process id: 0x11ec
Faulting application start time: 0x01d0bf9ffbb54cab
Faulting application path: D:\PathToSolutionFolderOnBuildServer\.sonarqube\bin\SonarQube.MSBuild.PostProcessor.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: 3cbfce4b-2b93-11e5-b84b-0050569a7ef0
Мы получили последнюю версию на Github и добавили дополнительное ведение журнала, чтобы выяснить, какая строка вызвала ошибку. Эта строка вызывает проблемы< /а>.
Воспроизведение
Мне удалось воспроизвести эту ошибку на моем локальном компьютере разработчика под управлением Windows 7 со следующим кодом. Когда я устанавливаю точку отладки в первом Assert, а затем пытаюсь получить доступ к свойству projectName
, наведя на него указатель мыши, это приведет к сбою всей моей Visual Studio.
[TestMethod]
public void TestMethod1()
{
using (TfsTeamProjectCollection collection = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri("http://tfs-url:8080/tfs/collectionname/")))
{
IBuildServer buildServer = collection.GetService<IBuildServer>();
string uri = "vstfs:///Build/Build/4238";
var buildUri = new Uri(uri);
IBuildDetail build = buildServer.GetMinimalBuildDetails(buildUri);
string projectName = build.TeamProject;
ITestManagementService tcm = collection.GetService<ITestManagementService>();
ITestManagementTeamProject testProject = tcm.GetTeamProject(projectName);
Assert.IsNotNull(testProject);
IBuildCoverage[] coverage = testProject.CoverageAnalysisManager.QueryBuildCoverage(uri, CoverageQueryFlags.Modules);
Assert.IsTrue(coverage.Length > 0);
}
}
В результате появляется следующее сообщение об ошибке:
Faulting application name: devenv.exe, version: 12.0.31101.0, time stamp: 0x54548724
Faulting module name: clr.dll, version: 4.0.30319.34209, time stamp: 0x5348961e
Exception code: 0xc0000005
Fault offset: 0x004c2b43
Faulting process id: 0x10e4
Faulting application start time: 0x01d0bf9ec962fde0
Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: 14f6496d-2b9b-11e5-a293-083e8ea0a055
Возможное решение
Ошибка ведет прямо к этой статье базы знаний. Нам не удалось применить это исправление.
Кроме того, мы удалили .NET framework 4, потому что версия 4.5.2 уже была установлена, и мы подумали, что они могут конфликтовать друг с другом. Теперь на сервере сборки все еще установлены только 4.5.1 и 4.5.2, и мы не уверены, какое решение может быть. В качестве последнего варианта мы рассматриваем возможность обновления сервера сборки в коллекции B до Windows Server 2012 R2, чтобы посмотреть, может ли это быть решением.
Изменить: исправлено
Из-за внутренней ошибки VS2013 был удален. Поэтому нам пришлось переустановить VS2013 и обновить 4. Мы также обновились до версии 1.0. Кажется, это решило проблему. Code Coverage теперь доступен на нашем веб-портале.