Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-19302

No code coverage statitics are generated for .NET x64 builds using vstestrunner plugin

      Where I work we are developing a .NET 4.5 application, and the application is compiled for 32-bit and 64-bit explicitly as we are reliant on unmanaged C++ binaries.

      Using the vstestrunner plugin I am able to get code coverage results for the 32-bit builds but not the 64-bit builds. Apart from the Platform and the Test Files parameters all other parameters are the same as seen in the attached images.

      Furthermore when I log into the Jenkins slave as the local Windows account that the Jenkins service runs under, I see that the generated TRX file has no code coverage results. However when logged onto the build server when I manually run the VSTest.Console.exe command with the same parameters used during the build I get code coverage results.

          [JENKINS-19302] No code coverage statitics are generated for .NET x64 builds using vstestrunner plugin

          I was able to reproduce this issue using a deomonstration Visual Studio .NET 2012/.NET 4.5 solution. The solution consists of a class library and a unit test project, and both are set to be compiled in 32-bit (x86) and 64-bit (x64) - "Any CPU" was removed from the solution platform.

          I then set up two Jenkins build jobs for this solution. Both jobs compile and run unit tests with code coverage. One does this for x86 and the other for x64.

          For the x86 job, code coverage results were generated. For the x64 job, no code coverage results were generated. After examining the Console Output for the x64 job, I logged onto the build machine with the same local user account configured to run builds on that machine, copied the VSTest.Console command used during the build and found that code coverage results were then generated.

          Hence it appears that there is an issue with Jenkins generating code coverage results for .NET 4.5 solutions for the x64 platform.

          Kosta Tenedios added a comment - I was able to reproduce this issue using a deomonstration Visual Studio .NET 2012/.NET 4.5 solution. The solution consists of a class library and a unit test project, and both are set to be compiled in 32-bit (x86) and 64-bit (x64) - "Any CPU" was removed from the solution platform. I then set up two Jenkins build jobs for this solution. Both jobs compile and run unit tests with code coverage. One does this for x86 and the other for x64. For the x86 job, code coverage results were generated. For the x64 job, no code coverage results were generated. After examining the Console Output for the x64 job, I logged onto the build machine with the same local user account configured to run builds on that machine, copied the VSTest.Console command used during the build and found that code coverage results were then generated. Hence it appears that there is an issue with Jenkins generating code coverage results for .NET 4.5 solutions for the x64 platform.

          To be more explicit, the 64-bit builds give a code coverage result of 0%, but when the exact same command is used on the build machine when logged onto it as the user running the builds, code coverage result of > 0% is generated.

          Kosta Tenedios added a comment - To be more explicit, the 64-bit builds give a code coverage result of 0%, but when the exact same command is used on the build machine when logged onto it as the user running the builds, code coverage result of > 0% is generated.

          Jonathan Shaw added a comment -

          I changed the Jenkins service to run under a local user account rather than the Local System Account and this resolved the problem for me. I am calling vstest.console.exe directly through an msbuild script rather than using the vstestrunner plugin, but I had the same symptoms as Kosta.

          Jonathan Shaw added a comment - I changed the Jenkins service to run under a local user account rather than the Local System Account and this resolved the problem for me. I am calling vstest.console.exe directly through an msbuild script rather than using the vstestrunner plugin, but I had the same symptoms as Kosta.

            Unassigned Unassigned
            ktenedios Kosta Tenedios
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: