Is it possible to obtain Code coverage numbers from VS 2012 Trial Version tool?
When I run my test cases (manually) after instrumentation, the .coverage file says my .pdb's may not be present or may be incorrect.
Is there something else i need to do?
For Instrumentation i do the Following:
use vsinstr with coverage flag and instrument the .dll and .exe
copy all .dll, .exe and .pdb file
I execute the test cases.
I am using Visual Studio ultimate 2012 Trial version downloaded from MSDN site
Try this :
tools ->options ->debugging->symbols->tick the check mark against microsoft symbol server
and click ok .
Related
In our Jenkins pipeline, we use SonarQube to report on our code coverage. After running all of our unit/integration tests to produce the .coverage file, we need to analyze this file to create the ".coverage.coveragexml" which is ultimately what is used by SonarQube to interpret the code coverage. We do this by using the CodeCoverage.exe:
"C:\Program Files (x86)\Microsoft Visual Studio\2022\TestAgent\Team Tools\Dynamic Code Coverage Tools\CodeCoverage.exe" analyze /output:"{somePath}\{someName}.coverage.coveragexml" "{somePath}\{someName}.coverage"
This command appears to be working, but when you run dir /s *.coveragexml (within the directory), it displays something like:
Directory of C:\jenkins\path\to\TestResults\coverageFile
03/22/2022 04:59 PM 64 ContainerAdministrator_DC420D3FA0BA_2022-03-22.16_46_43.coverage.coveragexml
1 File(s) 64 bytes
64 bytes is practically nothing - and I believe this is the reason why our SonarQube metrics show we have 0 coverage now.
I added the same dir command, only this time to check for the .coverage file(s), and those come back with only 10 bytes in them - making me think that these files are essentially empty. I saw this post that seems to be a similar issue. The accepted answer said to change the platform type from x86 to x64, but that did not work in my case.
The vstest.console command for running our tests is:
vstest.console /Parallel /EnableCodeCoverage /Logger:trx /Platform:x86 ".\somePath\Test.dll"
This issue originally started back when we made a change to our Jenkinsfile for it to use Visual Studio 2022 instead of 2019 (the base image was updated) in the command that started the CodeCoverage executable.
What could be causing the coverage files to be nearly/completely empty and how can I fix it?
It seems the base image we use must have a non-enterprise edition of the Code Coverage tools (which is a requirement). We tested our SonarQube projects commands locally using an enterprise edition of the tools (I have Visual Studio 2022 Enterprise installed on my machine), and the coverage files produced contain the correct data. However, when we used a Visual Studio Professional install, the files are empty just like our Jenkins pipeline.
As stated, this started happening when the base image was updated - in particular it was around November 8th 2021. It seems the base docker image we were using (mcr.microsoft.com/dotnet/framework/sdk:4.8-20220210-windowsservercore-ltsc2019) has the latest 2022 tools, but it must not be an enterprise edition - hence the empty files.
We switched our pipeline over to using dotCover instead to perform the analysis, which works as expected and our SonarQube coverage is back to normal.
TL;DR: Clean Windows build server, MS Build Tools 2019 and TFS 2013 installed.
Build Logs says Exception Message: File not found: MSBuild.exe (type FileNotFoundException)
How Do I setup MSBUILD toolpath in a XAML file on TFS 2013, configured to use MSBuild 2019 with a Visual Studio 2019 Enterprise installed on my dev box.
Please provide FULL XAML file that WORKS with TFS2013 (update 3) with an explicit custom msbuild path.
A Bit more info:
We have a multi server setup for our TFS build routines running version 2013.
One controller and a few agent servers here and there, nothing fancy.
Recently I added yet another for GUI Testing - I need the agent service to be in Interactive mode.
Steps so far:
Installed TFS 2013 including two agents - linking to the main controller.
I install Build Tools version 2019
I added tags to control the build destribution.
Activated a build and the rest is history.
I'm four (frustrating) days in on this - I've read every Stack Overflow TFS set toolpath entry I can find, and a huge bunch of odd forums, yet none seems to scratch my itch here.
I even added both paths you see further down, to the Windows environment PATH variable. Im not sure that does anything anymore.
See; Everybody talks about this entry in the XAML that says toolpath (or similar) - but; I dont see it. We use a minor changed version of a TfvcTemplate.12.Xaml.
Many also talk about this GUI tool for editing XALM files, where I get to see all the different options available (I presume) - can someone help me with this too? Its certainly not working out of the box with a 2019 Enterprise????
So; I installed this Extension Process Template Editor, but of course nothing happens when I click a XAML file, just more XML :)
I now have a few added paths on the new server, where I see instances of msbuild.exe installed (MS/.NET get your act together, please)
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin
C:\Program Files (x86)\MSBuild\12.0\Bin
Please try not to write this off as a duplicate at first glance. I know its similar to other questions - however; Devil is in the details.
Set toolpath to MSBuild 2019 in a TFS 2013 using (XALM) build process templates
Just as you know, the Old Visual Studio versions installed msbuild into C:\Program Files (x86)\MSBuild\<version>\bin and apparently the RunMSBuild activity used the ToolVersion + the ToolArchitecture to calculate this path.
VS 2019 build tool instead installs it C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin and the RunMSBuild can't calculate the proper path anymore. You can not use the old DefaultTemplate12.xaml to integrate with VS2019 build tool.
To make this work, you could try to modify the TFSBuildServiceHost.exe.config and you must have a version of VS 2019 build tool or VS2019 installed on the build server in order for this to work.
More detail step please follow Jonesy2488's answer in this link:How to get VS 2017 working with TFS 2017 XAML Builds.
Besides, we could also try to use MSBuild task instead of Visual Studio Build task, then specify the location of MSBuild 16.0:
Hope this helps.
I made it work by changing ToolVersion for mtba:RunMSBuild in TfvcTemplate.12.xaml to the required version and adding MSBuildToolsPath to Windows Registry.
Registry settings for 15.0 and 16.0
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\15.0]
"MSBuildToolsPath"="C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\BuildTools\\MSBuild\\15.0\\Bin\\amd64"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\16.0]
"MSBuildToolsPath"="C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\MSBuild\\Current\\Bin\\amd64"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild\ToolsVersions]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild\ToolsVersions\15.0]
"MSBuildToolsPath"="C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\BuildTools\\MSBuild\\15.0\\Bin"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild\ToolsVersions\16.0]
"MSBuildToolsPath"="C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\MSBuild\\Current\\Bin"
I'm working in C# on Visual Studio and my builds run on TFS.
This week I enabled code coverage via my tfs build (Let's assume that I have a .sln Names MySln and there is Tests.MySln there too).
The code coverage via tfs stood on 6% and it's weird because when I ran it with Visual Studio Code Coverage in Test Section I got 70% (which is more correctly).
After I downloaded the code coverage results from tfs I noticed that it somehow ran with more dlls that we're using via Nuget.
I tried some changes in .runSettings file, but when I added include only MySln.dll, I got 0 code coverage and I don't want to create runSettings that say exclude all the other dll I saw that ran (I have 15 different slns and I don't want to create a list that might change between projects). I even tried to just enable code coverage without changes of runsettings.
Does someone knows which 'settings' does Visual Studio Test Code Coverage deliver? which config?.
Or have another idea how to create .runSettings file?
Update
Op finally re-write the runSettings file fixed it.
This sounds like a configuration setting issue in Visual Studio or .runsettings file not related to TFS side.
Suggest you try to remote to the build agent and manually run the Code Coverage through the Visual Studio in remote agent directly. Check whether you get the same result if run it through TFS build server.
Is code coverage supported with Visual Studio Team Services by default, and can the team check the coverage result on their local visual studio instances? (coloring the coverage).
Yes, when you add "Visual Studio Test" step in your build definition, you can check the "Code Coverage Enabled" option:
And then you can see the code coverage information in the build report:
You can also download the code coverage results file into your local machine but you need to use VS Enterprise edition to open it.
Well i downloaded the newest version, then installed, checked to instal entire files on local drive. I restarted VS2010 and rerun it. Unfortunatelly i can't find in menu > tools anything with should be connected with stylecop ( as in tutorial "how to use stylecop"). I am using x64 Windows7.
I really really don't know how to to use it.
Look: I click inside code, white field and i see only this:
1) Download StyleCop from here
2) Close all Visual Studio instances
3) Install StyleCop
4) Open Visual Studio, Right click inside code file and you could see Run StyleCop Option
Are you using one of the Visual Studio Express products? If so, you will not see UI integration of StyleCop since the VS Express edition does not support integration of add-ins and packages like StyleCop.
If you are using Express, you could still run StyleCop, but this will require using either MSBuild integration or a pre- or post- build event.
It looks like it is possible to use StyleCop with Express edition. Here is how.