Integration of OpenCover with TFS - tfs

I am new to TFS and want to integrate OpenCover with TFS. If any has done this please help!

This question is rather old but maybe you are still interested. With current Version of TFS (2015 Update 2) this is now possible as a "vsts Extension".
See here for details: https://github.com/RobertK66/vsts-opencover

Since the answer doesn't specify the version of TFS, here is an answer for 2015/2017.
OpenCover can be run from TFS using the Powershell build step. You need to get the contents of the OpenCover NuGet package onto TFS and run OpenCover.console.exe from there.
Since TFS doesn't support the format produced by OpenCover, you need to take one additional step and convert the results to Cobertura format. It's possible using the OpenCoverToCoberturaConverter NuGet package.
I've described the whole process in much more detail on my blog:
http://codewithstyle.info/setting-up-coverage-reports-on-vsts-with-opencover/

OpenCover is just a console application so you can just modify your scripts to get OpenCover to run your unit tests.
I haven't used TFS for several years and it has changed since then however this blog post should help
To incorporate coverage measurement of OpenCover the build process of TFS (second half)
The original is in Japanese but if you are familiar with TFS then the screens will probably be obvious.
OpenCover also comes with an MSBuild task that may help you with your integration.

I've just integrated opencover with TFS Build, to generate a xml with the results that will be processed by sonar:
Created a RunCoverage.cmd at the root of my source folder
Installed / copied in TFS Servers the Opencover binaries and added into Path(must restart TFS Services to enable TFS to see it).
Created a new actitivity in the build definition, that is, editing the build template (before sonar execution activity) to run the cmd:
Running command line statements from TFS custom activity
http://msdn.microsoft.com/en-us/library/gg265783.aspx
There is the cmd contents:
#REM #echo suppresses command line. ^ is line continuation character
#ECHO Executing OpenCover...
OpenCover.Console.exe -register:user ^
-target:"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\MSTest.exe" ^
-targetargs:"/testcontainer:%~dp0test.dll /usestderr /resultsfile:%~dp0MSTestsResults.trx" ^
-output:%~dp0opencovertests.xml
But i'm facing three issues (that are related with my concrete implementation, but you may face them):
The Tests are runned twice (one for template itself, and other for OpenCover)
The MsTest.exe in the TFS Servers is not in the same path, so when the Controller asigns an agent (if the match is done by tags) then if the agent executing the build is in a TFS Server that does not have the MSTest in the right path it will fail.
How to inject in cmd the corresponding test runner (MsTest, XUnit, Nunit, etc...) depending on the test project
Hope that it helps! (and someone can help me ;-)

Related

TFS Build 2015 "Warning: Unable to create DiaSession for..." NUnit

When trying to run the unit tests as a build step in TFS Build 2015 (vNext), I get the following warning:
Warning: Unable to create DiaSession for <assembly>
No source location data will be available for this assembly.
The test assembly is then run, but the unit tests inside fail because they can't locate the references, I'm assuming because of the 'No source location data will be available' part of the warning.
The NUnit NuGet package I am using for the unit tests is: "NUnitTestAdapter.WithFramework" v2.0.0. The project is made in C#.
I've seen this question, but I don't really understand what they are saying, and it doesn't look like they are using TFS Build 2015 (vNext) build definitions.
Any ideas?
The question you referenced is talking about the old TFS build XAML not vNext build the one you are using.
However you could also use the same MSBuild arguments in vNext Visual Stduio Build or MSbuild task.
You need to use add the /p:NoWarn=warningNumber in MSBuild Arguments
in the build definition. Or use the /p:WarningLevel=0 argument to
suppress all warnings.
According to your error info, seems the issue should not related to TFS build side. Since unit tests inside fail because they can't locate the references, please try to directly run your tests on the build agent locally(remote to). This will help you to narrow down the issue. Besides, also Enable Verbose Debug Mode for TFS Build vNext by adding system.debug=true to see if there are more details log info for troubleshooting.

How do I get my Windows service solution to produce an artifact with VSTS Build?

I have a build definition in Visual Studio Team Services (a.k.a. Visual Studio Online? I'm not really sure the right name for it honestly) that is not producing an artifact, and I'm really not sure why. The main project in the solution file is a Windows service that is built using TopShelf. I suspect that maybe the MSBuild arguments in the Visual Studio Build task might be wrong. I copied them from a build definition for an MVC project that is working, but it occurs to me that they might not work for a Windows service.
Here they are:
/p:DeployOnBuild=true
/p:WebPublishMethod=Package
/p:PackageAsSingleFile=true
/p:SkipInvalidConfigurations=true
/p:PackageLocation="$(build.artifactstagingdirectory)\\"
I have a Copy Files task and a Publish Build Artifacts task later on in the process, but apparently the $(build.artifactstagingdirectory)\\ is empty. I get this warning:
##[warning]Directory 'd:\a\1\a' is empty. Nothing will be added to build artifact
Oddly enough, in another task in the process where I publish the symbols, everything appears to go off without a hitch.
One more bit: I'm using a hosted build agent. Not sure if that matters or not.
That's all of the pertinent information I can think to provide. Am I way off base here? I've used Octopus Deploy in the past and I know I had to install Octopack on my services. Do I need to do something similar here?
You don't need any of those MSbuild arguments; most of them apply to ASP .NET projects and will do nothing for a console application.
Replace them all with /p:OutDir=$(Build.ArtifactStagingDirectory). That will tell MSBuild to put the build outputs in the artifact staging directory.

How to use code coverage tools in continuous build integration of TFS 2013?

I am using the TFS 2013\VS 2013 professional editions for continuous build. Am looking to use an open source tool like OpenCover for code coverage. I have no prior experience in code coverage tools. I installed the OpenCover UI from Nuget but not sure how to include Codecoverage in integrated build in TFS. Getting "No Code Coverage Results" when the build runs.
I enabled code coverage under Automated tests node in build definition.
Any suggestion on how to implement code coverage in TFS\VS 2013 Profession edition would be greatly appreciated.
If you mean Enabled Code Coverage in the build definition just like below screeshot.
This is VS build-in code coverage, according to the Compare VS offerings site, only Visual Studio Enterprise has Code Coverage feature, so if you use TFS for your CI build and want to use the built-in code coverage feature, installing VS Enterprise on your build agent machine is required.
If you want to integrate OpenCover with TFS XAML build, you need to customize your build process template, add a custom activity in the build definition to trigger the opencover command for generating the report.
Created a RunCoverage.cmd at the root of my source folder
Installed / copied in TFS Servers the Opencover binaries and added into Path(must restart TFS Services to enable TFS to see it).
Created a new actitivity in the build definition, that is, editing the build template (before sonar execution activity) to run the cmd:
Running command line statements from TFS custom activity
http://msdn.microsoft.com/en-us/library/gg265783.aspx
There is the cmd contents:
#REM #echo suppresses command line. ^ is line continuation character
#ECHO Executing OpenCover...
OpenCover.Console.exe -register:user ^
-target:"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\MSTest.exe" ^
-targetargs:"/testcontainer:%~dp0test.dll /usestderr /resultsfile:%~dp0MSTestsResults.trx" ^
-output:%~dp0opencovertests.xml
More details please refer Naim Raja Díaz's answer in this similar question:Integration of OpenCover with TFS 

Forcing TFS 2013 to use VS 2015 as a Build Agent

Not too sure if what I'm asking here is possible, or if it requires an upgrade. My problem is that I have a local install of TFS 2013 (that is, on-premises), and all dev machines have now upgraded to VS2015. However, when using new features (such as $"test {teststring}"), we get build errors.
The build machine has both VS2013 and VS2015 installed, and is using the default build template (TfvcTemplate.12.xaml). Looking at the "Run MSBuild" task inside the build workflow, there doesn't seem to be any way to point it to one MSBuild or another.
Is it possible to hint to the build to use the later version of VS / MSBuild and, if so, how?
Try adding /tv:14 to the msbuild commandline arguments in your build template, if that doesn't work, edit the xaml file for your build process template and override the "ToolPath" property of the "Run MsBuild for Project" task. Or make that field configurable through further customization of the build template.
Set that path to C:\Program Files (x86)\MSBuild\14.0\Bin (or your equivalend location in case your machine uses alternate default directory names).

SSIS 2012 Continuous Integration with TFS 2013

I’ve been reading some articles (this one in particular: http://speaksql.wordpress.com/2013/06/07/a-journey-to-db-deployment-automaton-ssis-build-using-msbuild/) about using msbuild.exe to build and deploy an SSIS package (.ispac). I had no problem with that from my computer which has all the required assemblies, and only using the msbuild.exe command.
Once I tried to use the TFS Build Server I had some problems. First I realized that using a project with msbuild.exe (SSIS.MSBuild.proj) was not recommended with TFS 2013 since it was used with TFS 2008 and 2010. Anyway, I just wanted to make it work and it sounded plausible, but I had to use the TFSBuild.proj. That was not a problem, but my next problem was that the project I was being using (Microsoft SQL Server Community Samples: Integration Services) references a SQL Server assembly (Microsoft.SqlServer.ManagedDTS) which is not installed on my build server.
Then I realized that even if I managed to install that assembly on the gac, or referenced it on a relative path I would have a bigger problem next, I am using custom activities on my packages which I need to install using gacutil.exe on the host server, and I was wondering how to install, remotely, those dll.
That’s when I started to lose faith, and here I am, is there an “easy” way to implement continuous integration for SSIS packages without installing third party tools (http://remotegacutil.codeplex.com/ for example), and adding missing assemblies to the gac of a build server?
Did any of you have a similar issue? Did you solve it? How?
Thanks!
Use devenv.exe to build the ispac. Add an invoke process task and call out to devenv.
Add an Invoke Process to the Build Template, the one above shows a Sequence container, which assigns the path to the correct version of DeVenv to call, VS2010 /12 /13 etc. this is shown as hard coded but can be put into an argument, so it can be populated in individual build definitions. the one you can't see clearly is "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.com"
Next is the invoke Process, this call out to the specified devenv.exe and passes arguments used to build the ISPAC file.
The arguments are passed in localProject would get you the actual project you wanted to build in previous versions, you may have to do something different for 2013, due to the changes to the new templates.
this gives a TFS2012 way of doing it, as i say you may have to do something different to get the project that you want to build under 2013, but the build will run and an .ISPAC file will be generated.
at this point i would deploy the ISPAC using powershell, you may want to add additional scripts to the powershell calls to handle creating the SSIS Catalog and scheduling of the job.
deploying with Powershell can be found here Deploying ISPAC's with Powershell

Resources