TFS 2017 test task run fails on VS 2017 build machine if code coverage is enabled - code-coverage

We're executing a number of tests on a build machine with VS 2017 Enterprise where we've enabled code coverage on the Visual Studio test task. This fails with the following error in the TFS 2017 console:
##[section]Starting: Test Assemblies **\*test*.dll
Preparing task execution handler.
Executing the powershell script: d:\builds\4\_tasks\VSTest_ef087383-ee5e-42c7-9a53-ab56c98420f9\1.0.60\VSTest.ps1
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\TestPlatform
Working folder: d:\builds\4\3\s
Executing C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\TestPlatform\vstest.console.exe "d:\builds\4\3\s\Source\u.a.testassembly.dll" /Settings:"C:\Users\username\AppData\Local\Temp\tmp9CCF.tmp" /EnableCodeCoverage /logger:trx /TestAdapterPath:"d:\builds\4\3\s"
Microsoft (R) Test Execution Command Line Tool Version 15.0.0.0
Copyright (c) Microsoft Corporation. All rights reserved.
##[error]The test source file "/EnableCodeCoverage" provided was not found.
With Visual Studio 2015 enterprise the tests were executed with code coverage with no error.
We're supplying the path for the vstest.console.exe file as a custom path.
If I disable code coverage in the checkbox for the TFS 2017 'Visual Studio Test' task and use a runsettings file with no code coverage collectors specified, the tests are executed, but no code coverage is reported.
I've also tried with the code coverage checkbox disabled and the
/EnableCodeCoverage
argument supplied as a commandline parameter on the test tasks. That provides the same error as above.
I've found a number of people having issues with code coverage in VS 2017 but that mostly seems related to .NET core project?
Thank you for your help! :-)
UPDATE 1
If I try to run vstest.console.exe through the developer command prompt I'm unable to successfully specify the /EnableCodeCoverage option. It provides the following error message:
Microsoft (R) Test Execution Command Line Tool Version 15.0.0.0
Copyright (c) Microsoft Corporation. All rights reserved.
The test source file "/EnableCodeCoverage" provided was not found.
This errormessage does not appear if I run the exact same command without the above switch.
Update 2
If I use a Runsettings file instead, in which I specify the datacollectors, I get a JSON related error:
Cannot deserialize the current JSON object (e.g. {"name":"value"})
into type 'System.Collections.ObjectModel.Collection`1 Microsoft.VisualStudio.TestPlatform.ObjectModel.AttachmentSet]'
because the type requires a JSON array (e.g. [1,2,3]) to deserialize correctly.
If I use the /Diag switch I get the following stacktrace in a logfile:
Stack Trace:
ved Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateObject(JsonReader reader, Type objectType, JsonContract contract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerMember, Object existingValue)
ved Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)
ved Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)
ved Newtonsoft.Json.Linq.JToken.ToObject(Type objectType, JsonSerializer jsonSerializer)
ved Newtonsoft.Json.Linq.JToken.ToObject[T](JsonSerializer jsonSerializer)
ved Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.JsonDataSerializer.DeserializePayload[T](Message message)
ved Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.DataCollection.ProxyDataCollectionManager.<>c__DisplayClass6_0.<AfterTestRunEnd>b__0()
ved Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.DataCollection.ProxyDataCollectionManager.InvokeDataCollectionServiceAction(Action action, ITestMessageEventHandler runEventsHandler)
Update 3
Our build server is a Windows 2012 standard server. We were able to install VS 2017 without any errors except for the installation of the Windows SDK payload. We had to manually install Windows SDK for Windows 8 afterwards as Windows SDK payload included in the VS 2017 Enterprise didn't install on Windows server 2012.
I've just noticed that Windows Server 2012 isn't on the list of supported operating systems for VS 2017?...
Update 4
The detailed output from
vstest.console.exe /?
when run from the VS 2017 developer command prompt is:
Microsoft (R) Test Execution Command Line Tool Version 15.0.0.0
Copyright (c) Microsoft Corporation. All rights reserved.
Usage: vstest.console.exe [Arguments] [Options] [[--] <args>...]]
Description: Runs tests from the specified files.
It then lists all of the arguments. The
/Enablecodecoverage
switch is nowhere to be found. The Developer Command Prompt is opened using the shortcut in the Start menu.
I've tried to run a test suite where the datacollector was defined in a .runsettings file instead of using the /enablecodecoverage switch, but that produces the JSON error listed above.
Update 5
After upgrading our TFS on-premise to 2017 update 1 we we're able to successfully execute our unit tests AND get code coverage.
We are however using SonarQube and apparently at this time of writing the SonarQube scanner provided in the Marketplace Extension v. 3.0.0 doesn't correctly locate the code coverage report due to the change in registry keys done in VS 2017.
A bug report has been filed with SonarQube on this issue.
You can get around this limitation by manually creating a registry value named 'ShellFolder' under the follow registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\15.0
The 'ShellFolder' string value should then be:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise
I've left the above information here in case somebody else comes looking with same problems that we had.

The reason is that there isn’t /EnableCodeCoverage option if call vstest.console.exe tool directly. (Sepecify vstest.console.exe path for Visual Studio Test step/task). If call vstest.console command through Developer Command Prompt for VS 2017, it has /EnableCodeCoverage.
To deal with this issue, you can upgrade your TFS 2017 to TFS 2017 update 1, then select 2.* version of Visual Studio Test step/task, after that you can select Visual Studio 2017 option for VSTest version.
Update:
Another workaround is that, you can install agent for VS 2017 (Tools for Visual Studio 2017) on build agent, then specify vstest.console.exe path in test agent installation folder for Visual Studio Test step/task. (C:\Program Files (x86)\Microsoft Visual Studio\2017\TestAgent\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe)

Related

Why did my automated Visual Studio builds suddenly stopped building?

I have a Visual Studio project that I have been automatically building in GitLab CI for quite some time without any issues. I'm building the solution simply with:
devenv.exe MySolution.sln /Build "Release|x64"
Today, the builds suddenly and silenty started to fail. I have made no changes at all and the build command provides no output either. What is going on?
The most likely cause for Visual Studio builds suddenly starting to fail is an expired Visual Studio license.
Resolving silent build failures
The reason you're not seeing any output is that you're invoking devenv.exe, which is not designed to output to stdout as it's a desktop application.
In your build scripts, you're going to want to use devenv.com. Once you do so, you'll see the following output instead:
Microsoft Visual Studio 2019 Version 16.8.3.
Copyright (C) Microsoft Corp. All rights reserved.
The license for Visual Studio has expired.
The evaluation period for this product has ended.
Resolving expired license
On your build machine, open Visual Studio and check if the license is still valid. Note however, that you need to start Visual Studio with the same user account your build runner uses.
For GitLab CI on a Windows machine, where it's running as a service, Visual Studio will run as the SYSTEM user. So you need to start is as the SYSTEM user as well.
To do so, use psexec. For example:
PsExec.exe -si "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\devenv.com"
You will most likely be greeted by a dialog asking you to log in to update your license. Upon completion, your builds will be running smoothly again.

Upgraded TFS, Build/Test Controllers/Agents and VS to 2013, now CodedUI tests not executing due to missing 2012 assembly reference

We just upgraded from TFS/VS2012 to TFS/VS2013 and now no CodedUI tests can be executed as part of a build workflow. I now get the following error when running any test as part of a build workflow:
Error adding test case [<#>] to test run: Unable to load the test
container "\\.dll" or one of its dependencies.
Error details: System.IO.FileNotFoundException: Could not load file or
assembly 'Microsoft.VisualStudio.TestTools.UITesting, Version =
11.0.0.0, Culture=neutral, PublicKeyToken=' or one of its dependencies. The system cannot find the file specified.
Our setup is as follows:
TFS Server:
Windows Server 2012 Standard
TFS 2013 Update 2 (12.0.30324.0)
Visual Studios is NOT installed
Build Server (Used to create the build A):
Windows 7 Professional Service Pack 1
TFS 2013 Update 2 (12.0.30324.0)
Visual Studio Premium 2012 (11.0.50727.1)
Visual Studio Premium 2013 (12.0.21005.1)
Agents for Visual Studio 2013 (12.0.21005.1) (NOTE: These are not
used for this build/deploy/test workflow)
Build/Test Controller (Used to trigger build A on the above server, then execute the deploy/test workflow/build B):
Windows Server 2008 R2 Standard
TFS 2013 Update 2 (12.0.30324.0
Test Controller for VS2013 (12.0.21005.1)
Visual Studio Premium 2013 (12.0.21005.1)
Visual Studio Test Professional 2013 (12.0.21005.1)
Test Agent:
Windows Server 2012 Standard
Agents for Visual Studio 2013 (12.0.21005.1)
Development Environment:
Windows Server 2012 Standard
Visual Studio Premium 2013 (12.0.21005.1)
Visual Studio Test Professional 2013 (12.0.21005.1)
In our environment, Build A is the build that creates the build/setup packages. Build B is what deploys the build/setups to a lab environment and executes the tests.
I can run the tests without issue from the dev environment, on the dev
environment
I cannot run the tests via mstest cmdline from the controller
The DLL Microsoft.VisualStudio.TestTools.UITesting exists at "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\PublicAssemblies" on both the Test Controller and the Test Agent, but the version = 12.0.21005.1, not 11.0 which is what the error is complaining about
If Microsoft.VisualStudio.TestTools.UITesting version 12.0 is replaced with version 11.0 from another machine for troubleshooting purposes, the same error displays but for each of the following dll's:
Microsoft.VisualStudio.TestTools.UITest.Common
Microsoft.VisualStudio.TestTools.UITest.Extension
Microsoft.VisualStudio.QualityTools.CodedUITestFramework
Microsoft.VisualStudio.QualityTools.UnitTestFramework
After replacing all of the above version 12.0 DLL's with version 11.0 DLL's, I then get the following error when firing off Build B:
Failed to initialize the unit test extension 'urn:CodedUITest': A unit
test extension is not registered for the following attribute:
Microsoft.VisualStudio.TestTools.UITesting.CodedUITestAttribute
I've tried everything I could think of or find online to troubleshoot this issue, but I'm all out of ideas. Any suggestions on where to go from here to get my CodedUI tests running again? In theory, TFS, Build Controller/Agent, Test Controller/Agent and VS are all upgraded to 2013, so why are 2012(version 11) dll's needed?

Delphi XE3 build batch failed to run msbuild using Hudson or Jenkins

I try to configure Hudson (3.1.0) to build Delphi XE3 project (MSBuild).
Batch for build:
call "C:\Program Files (x86)\Embarcadero\RAD Studio\10.0\bin\rsvars.bat"
msbuild "X:\Tests\DelphiTest\Project1Test.dproj" /t:Build /v:minimal /p:config="Debug"
Run this batch in command line (cmd.exe) - build correct.
When I put this batch into Hudson build step faild with errors from delphi compiler:
[..]
C:\Program Files (x86)\Embarcadero\RAD Studio\10.0\bin\CodeGear.Common.Targets : warning : Expected configuration file missing - C:\Windows\system32\config\systemprofile\AppData\Roaming\Embarcadero\BDS\10.0\EnvOptions.proj
_PasCoreCompile:
Embarcadero Delphi for Win32 compiler version 24.0
Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
C:\Program Files (x86)\Embarcadero\RAD Studio\10.0\Bin\CodeGear.Delphi.Targets(172,5): error E1026: File not found: 'Controls.res'
[..]
In fact I don't have missing file in this location. But I've found it in
C:\Users\<username>\AppData\Roaming\Embarcadero\BDS\10.0
So I try do dummy think like copy existing dir to missing location but it doesn't work.
I'm using: Delphi XE3 Enterprise, Win 7 Ultimate (x64)
Thanks for help.
this usually happens the first time you run MSBUILD or DCC32 on a machine which has never had the IDE gui open (bds.exe) and which has passed the mandatory startup environment configuration tasks that happen inside BDS.exe.
If you log in on Hudson or Jenkins as a Windows service using an account that has never been used for Windows logins, has never run BDS.exe, you will get this issue. The MSBUILD utility from Microsoft must invoke DCC32, which is licensed commercial software, and the Delphi command line compilation licensing and environment configuration requires that you have run the IDE as the account, and that your jenkins build account and computer is licensed properly.
Solution:
Either change Jenkins or Hudson to log in as an account that has a license to run Delphi, and has run Delphi at least once.
If you can't change the server login, then log in interactively (via remote desktop) using the account that Jenkins/Hudson is using, and configure Delphi (Rad Studio) so it runs fine from that account.
Update 2015: I am now running into a whole new class of problems related to Group Managed Service Accounts. They were working with Delphi XE8, but I am not able to get a GMSA account to work with Delphi 10 Seattle. I'll update this answer if I ever do figure out a way, but for now, I recommend conventional service accounts, not GMSAs, for Delphi continuous integration with Jenkins or Continua, or others. Also check Delphi.wikia.com for more tips: http://delphi.wikia.com/wiki/Setting_up_a_Delphi_Build_Machine
We recently ran in a similar kind of problem. We are trying to compile our projects on an jenkins. We simplified the "build" script to the following 2 lines
call "[....]Embarcadero\Studio\18.0\bin\rsvars.bat"
MSBuild.exe /p:config=Release /target:Rebuild Project2.dproj
This is building the project successful.
But when we switch to /p:config=debug the build fails with the known errors about missing *.res files. We looked up in the delphi lib/win32/ directory and realized that there are *.res files in the release folder but not in the debug folder. We now further modified the msbuild command to this:
MSBuild.exe /p:config=Release /target:Rebuild /p:ResourcePath="%BDS%\lib\win32\release" Project2.dproj
And this is compiling just fine. So apparently the compiling in debug mode lacks the path to the delphi sources (which are included in several subfolders in %BDS%\source\
So as a workaround we can compile debug builds using jenkins and simply giving delphi the *.res files from its release folder. But that can only be an intermediate solution.
Maybe this information helps someone to find a final solution which is not "Adding all subfolders of %BDS%\source into the search path" ;-)

TFS Build is failing Because of Missing Programs

I am trying to build a project using TFS2010 Build.TFS resides on its own server, and i am trying to build to a directory on the same machine. The Server does not have VS2010 installed on it.
When the build runs it fails and gives me this error:
c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (1558): Task failed because "AxImp.exe" was not found, or the correct Microsoft Windows SDK is not installed. The task is looking for "AxImp.exe" in the "bin" subdirectory beneath the location specified in the InstallationFolder value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A. You may be able to solve the problem by doing one of the following: 1) Install the Microsoft Windows SDK. 2) Install Visual Studio 2010. 3) Manually set the above registry key to the correct location. 4) Pass the correct location into the "ToolPath" parameter of the task.
Then I get a whole bunch of errors saying the namespaces of the project I am building cannot be found. I am not sure if that is all linked to the above mentioned error however.
Thank You!
It is recommended to have Visual Studio 2010 installed on your build machine but it is not a requirement. Since the error message indicates that it didn't find AxImp.exe, can you verify if this file exists on the build machine? The location is C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin (if you're on a 64-bit Windows).
If the file doesn't exist, installing .NET Framework SDK will probably help to resolve that specific error.
Regarding installing Visual Studio on the build machine, Visual Studio is licensed per user, not per machine, so as long as the build machine owner is licensed, you should not need extra license for Visual Studio. But you probably should look at the licensing papers for your edition of Visual Studio 2010 to make sure.
Here's a table in the white paper on licensing:
You need to have the same software running on the build server as you would if building locally. This means you need Visual Studio 2010, and possibly even the same edition of Visual Studio 2010, depending on what you're trying to build.
IMPORTANT REMINDER: Visual Studio is licensed PER USER. This means that as long as you as a user have a license, you can use that SAME LICENSE on your build Machine.
The only "problem" would be if you actually had "No licenses" - meaning you do not own a copy of Visual Studio at all, but have a legal copy of TFS.

How to get tf.exe (TFS command line client)?

What's the minimum amount of software I need to install to get the 'tf.exe' program?
You need to install Team Explorer, it's best to install the version of Team Explorer that matches the version of TFS you are using e.g. if you're using TFS 2010 then install Team Explorer 2010.
2012 version http://www.microsoft.com/en-gb/download/details.aspx?id=30656
2013 version http://www.microsoft.com/en-us/download/details.aspx?id=40776
2019 version https://visualstudio.microsoft.com/downloads/#visual-studio-team-explorer-2019
You also might be interested in the TFS power tools. They add some extra command line features (using tfpt.exe) and also add some extra IDE features.
I'm in a virtual machine, and am trying to keep my VHD as small as possible, so I find Team Explorer is a really heavyweight solution (300+ MB install). As an alternative, I've had some luck copying a minimal set of EXEs/DLLs from a Team Explorer installation to a clean machine (.NET 4.0 is still required, of course).
I've only tried a handful of operations so far, but this set of files (about 8.5 MB) has been enough to get basic source-control functionality via tf.exe:
TF.exe
TF.exe.config
Microsoft.TeamFoundation.dll
Microsoft.TeamFoundation.Client.dll
Microsoft.TeamFoundation.Common.dll
Microsoft.TeamFoundation.Common.Library.dll
Microsoft.TeamFoundation.VersionControl.Client.dll
Microsoft.TeamFoundation.VersionControl.Common.dll
Microsoft.TeamFoundation.VersionControl.Controls.dll
(It should go without saying that this is a completely unsupported solution, and it doesn't free you from the normal TFS licensing requirements.)
Depending on the operations you perform, you may find that additional DLLs are required. Fortunately, tf.exe will produce a nice error message telling you exactly which ones are missing.
For Visual Studio 2017 & 2019, it can be found here :
-Replace {YEAR} by the appropriate year ("2017", "2019").
-Replace {EDITION} by the appropriate edition name ("Enterprise", "Professional", or "Community")
C:\Program Files (x86)\Microsoft Visual Studio\{YEAR}\{EDITION}\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\tf.exe
For Visual Studio 2022, it can be found here :
C:\Program Files\Microsoft Visual Studio\2022\{EDITION}\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\TF.exe
There is a Java TFS client in the Team Explorer Everywhere installation (together with an Eclipse plugin). Look at http://www.microsoft.com/en-us/download/details.aspx?id=30661
For reference: these are the required DLLs for Visual Studio 2017 (as did #ijprest for the VS 2010)
TF.exe
TF.exe.config
Microsoft.TeamFoundation.Client.dll
Microsoft.TeamFoundation.Common.dll
Microsoft.TeamFoundation.Core.WebApi.dll
Microsoft.TeamFoundation.VersionControl.Client.dll
Microsoft.TeamFoundation.VersionControl.Common.dll
Microsoft.TeamFoundation.VersionControl.Controls.dll
Microsoft.VisualStudio.Services.Client.Interactive.dll
Microsoft.VisualStudio.Services.Common.dll
Microsoft.VisualStudio.Services.WebApi.dll
They will be in my base VM image. I'm going to use it to pull the latest deployment scripts from VC to a temporary local workspace folder when installing a new server.
tf workspace /new ...
tf workfold /map ...
tf get "%WorkSpaceLocalFolder%" /recursive
tf workfold /unmap
tf workspace /delete
<run deployment scripts from "%WorkSpaceLocalFolder%" >
rmdir "%WorkSpaceLocalFolder%"
(Sorry to post this as an answer, but I don't have enough reputation to comment, which I believe it should have been)
The tf.exe command line is included in the VSTS agent package in folder externals\vstsom.
You can also try TFS CLI for Node.js which is a cross-platform CLI for Microsoft Team Foundation Server and Visual Studio Team Services.
Visual Studio 2017 Team Explorer
According to https://blogs.msdn.microsoft.com/bharry/2017/04/05/team-explorer-for-tfs-2017/ you can now download it separately from Visual Studio via this link:
https://www.visualstudio.com/thank-you-downloading-visual-studio/?sku=TeamExplorer&rel=15
Following on from the earlier answers above but based on a VS 2019 install ;
I needed to run "tf git permission" commands, and copied the following files from:
C:\Program Files (x86)\Microsoft Visual Studio\2019\TeamExplorer\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer
Microsoft.TeamFoundation.Client.dll
Microsoft.TeamFoundation.Common.dll
Microsoft.TeamFoundation.Core.WebApi.dll
Microsoft.TeamFoundation.Diff.dll
Microsoft.TeamFoundation.Git.Client.dll
Microsoft.TeamFoundation.Git.Contracts.dll
Microsoft.TeamFoundation.Git.Controls.dll
Microsoft.TeamFoundation.Git.CoreServices.dll
Microsoft.TeamFoundation.Git.dll
Microsoft.TeamFoundation.Git.Graph.dll
Microsoft.TeamFoundation.Git.HostingProvider.AzureDevOps.dll
Microsoft.TeamFoundation.Git.HostingProvider.GitHub.dll
Microsoft.TeamFoundation.Git.HostingProvider.GitHub.imagemanifest
Microsoft.TeamFoundation.Git.Provider.dll
Microsoft.TeamFoundation.SourceControl.WebApi.dll
Microsoft.TeamFoundation.VersionControl.Client.dll
Microsoft.TeamFoundation.VersionControl.Common.dll
Microsoft.TeamFoundation.VersionControl.Common.Integration.dll
Microsoft.TeamFoundation.VersionControl.Controls.dll
Microsoft.VisualStudio.Services.Client.Interactive.dll
Microsoft.VisualStudio.Services.Common.dll
Microsoft.VisualStudio.Services.WebApi.dll
TF.exe
TF.exe.config

Resources