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.
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"
When I build a C# program (this has been going on for several different solutions/projects I have been working on) in Visual Studio 2017, the new, updated code will build and run in debug mode (and run correctly).
However, the application that Visual Studio has been outputting when I build/debug them has been remaining with the original, first version of code that I saved. When I choose the options to rebuild, it will update the time stamp on the application and .pdb files, but the application will perform the way it did in earlier code versions, not the most recent code version that was running problem when I ran debug mode immediately after pressing Ctrl + F5.
These are C# Console Apps with the .NET Framework 4.6.1, if that makes any difference. I checked the output folder, and it is indeed the desired folder and the one I have been looking in... so why is the time stamp updating on the application (.exe file) that it outputs, but not the code itself? What am I missing?
When I run into strange things like this in Visual Studio, the first thing that usually works is to clean the project and rebuild. If that doesn't work, I'll close Visual Studio, re-launch, then clean and rebuild again. If that doesn't work, I would start looking into any extensions you have installed that might be getting in the way of your build process.
Further, you can look into logging the extensions activity to help troubleshoot if there are issue there. See the following article:
https://blogs.msdn.microsoft.com/visualstudio/2010/02/24/troubleshooting-extensions-with-the-activity-log/
You may have already tried this, but since it wasn't mentioned I thought I'd provide it for others in a similar situation.
Two possible reasons:
(1) Your project was not recompiled during debugging. Please enable Edit and Continue under TOOLS->Options->Debugging.
(2) Visual Studio has a concept of incremental build. If you have a solution with two or much more projects and if you change source code in only one of the two projects, the "Build" command will compile only the modified project. But the "Rebuild" command, on the other hand, it will recompile all projects in this solution.
In short: I need to open an application originally built in Visual Studio 2008 (version 9) in Visual Studio 2013 without upgrading the project since the overall project architecture must remain the same for when I check it back into source control.
Details: I need to open a Visual Studio solution (.sln) inside Visual Studio 2013. The solution in question was originally developed in Visual Studio 2008, so when I try to open said solution in Visual Studio 2013, I am shown a prompt with the projects within the solution checkmarked, with the message:
These projects are either or supported or need project behavior impacting modifications to open in this version of Visual Studio. Projects no displayed either require no changes or will automatically be modified such that behavior is not impacted. Visual Studio will automatically make functional changes to the following projects in order to open them. You will not be able to open these projects in the version of Visual Studio in which they were originally created.*
My attempt at a fix was to just upgrade the solution and hope for the best. This is successful, but after building and attempting to run the main project, I see the following build error:
The type 'Microsoft.Web.Services3.WebServicesClientProtocol' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. *
I then tried both commenting out the references to this assembly and adding in the missing reference. Okay, so then I rebuilt the solution and attempted to run. Same error, but for a different assembly. Repeat fix, same error for different assembly. This pattern continues and continues, and at this point I realize this is unacceptable anyway, because when I make a change to this solution, I need to check it back into source control. When others open it, they may be opening it in VS2008, and therefore this “upgraded” version is inconsistent with the version the business uses. I need to open the solution originally build in VS2008 in VS 2013 (can't work around this, needs to be VS2013). If it helps, I'm using 64 bit Visual Studio 2013 Ultimate.
Any help or guidance will be greatly appreciated!
As several of the commenters have already helpfully pointed out, this is not possible. Round-tripping (i.e., opening and manipulating project files created by an older version of Visual Studio in a newer version of Visual Studio) was not supported until Visual Studio 11. The only way to open a Visual Studio 2008 project/solution in a later version of Visual Studio will be to convert it.
As far as interoperability with previous versions is concerned, you have two options:
Update the project locally (using the migration wizard provided), make any changes to the project file necessary to get it to build, and then edit the code files. Once you're satisfied with your edits, commit only the modified source files, not the project infrastructure files. Your fellow developers, stuck on VS 2008, won't notice any difference.
Update the project locally (using the migration wizard provided), make any changes to the project file necessary to get it to build, and then rename the project file (e.g., by appending a -vs2013 suffix to it). Commit this to your code repository. You will now have two project files in your root directory, one for each version of Visual Studio that your team works with. From here on, you just open the project file corresponding to the version of VS that you have installed.
I used approach #1 for a good part of last year, where I spent most of my time developing a C++ application in VS 2010 on a desktop machine, but also wanted to work on it on my notebook running VS 2013. Of course, in my case, it took a trivial amount of time for the automatic conversion to upgrade my project file after pulling from source control. I didn't have to do any tweaking thereafter to get the project to build. It sounds like your case is different, so option #2 might be a better choice.
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 .