In TFS Test Task I know that I can manually set the location of vstest.console.exe via:
this is less than an ideal solution though since, as I update my build server, this location may become invalid. The problem that I have run into is that if I select 'Version' my build server ends up using the vstest.console at this location:
C:\Program Files (x86)\Microsoft Visual Studio\2017\ SQL\Common7\IDE\CommonExtensions\Microsoft\TestWindow
I am guessing that this SQL Folder is the SQL Server Data Tools folder that is installed on the build server. This folder location isn't generally a problem, vstest runs my unit tests and reports back on them, however, it doesn't produce a code coverage report. I initially thought that this was due to an improper configuration of the builds, however after verifying that the build was setup correctly and that the server had all of the necessary dependencies I started looking for other causes. I opened up the .trx file from one of the builds and noticed that the DataCollector logged a message that it couldn't find CodeCoverage.exe. After some more troubleshooting, I pointed my build to the location of the vstest.console shown in the image above and everything (tests, code coverage) ran fine. This leads me to believe that vstest expects the path:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Team Tools\Dynamic Code Coverage Tools
to exist relative to where it is run from and that directory (Dynamic Code Coverage Tools) does not exist inside the SQL folder.
Is there a way to change the path that TFS uses when the 'Version' checkbox is checked?
VsTest task uses vswhere.exe in order to determine the latest version of VS installed in the machine. Can you try to run vswhwere.exe and check which version of VS is installed at C:\Program Files (x86)\Microsoft Visual Studio\2017\ SQL folder and is it higher than other versions, also check whether its an enterprise installation or not. As code coverage is provided as part enterprise installation only.
You will be able to find vswhere.exe in agent working folder as per VSTest task version eg.
C:\Temp\Agents\127Agent_work_tasks\VSTest_ef087383-ee5e-42c7-9a53-ab56c98420f9\2.3.19\vswhere.exe
Related
We have been using TFS to run automated tests. The tests run either as part of a build or on demand from a Test Plan. We are using Specflow to generate the test scenarios.
For the first month that I was executing these tests, a .TRX file would be generated that contained some logs from specflow. I could also log my own trace logs using System.Diagnostics.Trace.WriteLine. All of that would show up in the .Trx file.
The .TRX file would also show the number of tests that passed, failed, or were inconclusive. If I opened the file in Visual Studio, it would show me a Test Run panel with details on each test and their results.
Recently, however, that stopped happening. The .TRX file is still created, but it is basically empty. It says that no tests were run and all of my Trace logs dont display. TFS still shows me the correct information when I am logged in to the console, but the attached .TRX file is always 2k, meaning its just the skeleton of an xml file.
Here are some details of how we run the tests:
We have a Test Plan, so the Tests run as part of a Release. The Release contains a single Run Visual Studio Test Task
The .runSettings file only contains the TestRunParameters sections. No other settings are configured.
We are using TFS 2017 Version 2.
I thought that maybe Specflow had something to do with it, but even a simple MSTest without Specflow wont log correctly.
Some answers have suggested add /Logger:trx to the Other Console Options, but that always leaves me with a Warning stating that the Release is running on multiple agents so that settings will be ignored. Our release isnt runnin on multiple agents, so I dont know why I see that warning.
This worked until recently, and I have tried to figure out what has changed. I tried creating a brand new build, new code base, and new tests to run but it doesnt seem to matter.
Let me know what additional information you need. Thanks
I have figured out how to fix the issue, but I dont understand what exactly happened so I hope someone can fill in the blanks.
There are multiple versions of VSTest.Console.Exe on the TFS server. The one that is used when I select Visual Studio 2017 as the version is
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe
I dont know if that is correct or not, but that is what was being used. I noticed that locally I was using a different path.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe
I was able to execute that version of vstest and generate TRX files locally. There is also ANOTHER vstest.console.exe located at
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\Extensions\TestPlatform\vstest.console.exe
I believe that last one is for VSTest V2? Im not entirely sure and would love someone to clarify that.
I believe which executable you run depends on the Test Platform Version setting. I normally had it set to Latest, but I changed it to Visual Studio 2017 while trying to figure out why it wouldnt log anymore.
TLDR - The Solution
You can, alternately select Specific Location, which allows you to provide a path to the executable. I set the Path to vstest.console.exe value to C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe and everything works fine.
The only thing I can think of is that the version of Vstest under Professional (the version of Visual Studio we are using) is different from the one under BuildTools? The test would run successfully either way, but the executable under Professional also generates the Trx file. Since no details are logged, its hard to tell what is going on.
Hopefully someone can explain what is going on here, but at least anyone who has this same issue has something to try.
I have configured TeamCity to work with our TFS repo. I have configured the VCS Root and used the "Test Connection" to ensure that the settings are all correct. When I run a build it gets to the "Updating sources" and just hangs there. Here's the build log.
[13:33:45]Collecting changes in 1 VCS root
[13:33:47]Clearing temporary directory: D:\TeamCity\buildAgent\temp\buildTmp
[13:33:47]Publishing internal artifacts
[13:33:48]Using vcs information from server. Reason: no revision information for build configuration "Build Development trunk" and checkout directory D:\TeamCity\buildAgent\work\db23c120e1319dcb on agent
[13:33:48]Clean build enabled: removing old files from D:\TeamCity\buildAgent\work\db23c120e1319dcb
[13:33:48]Checkout directory: D:\TeamCity\buildAgent\work\db23c120e1319dcb
[13:33:48]Updating sources: server side checkout (1m:21s)
[13:33:48][Updating sources] Will perform clean checkout
[13:33:48][Updating sources] Clean checkout reasons
[13:33:50][Updating sources] Building and caching clean patch for VCS root: Development trunk
The checkout folder is empty. Any ideas?
EDIT
I've written a Windows batch file that gets the code out from TFS rather than using TeamCity to do this. My batch file runs perfectly when run from the Windows command prompt but fails when run from TeamCity. I am using the fully qualified path to TF.EXE because TeamCity doesn't seem able to find TF.EXE (even though the path has been added to the PATH environment variable).
My batch file correctly configures the TFS workspace before trying to GET the source code. But it still fails.
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" workspaces /collection:http://code-srvr1:8080/tfs/DefaultCollection
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" workspaces /s:http://code-srvr1:8080/tfs/DefaultCollection
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" workfold //fails!!
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" get $/MSM\Development\Trunk /force /recursive //fails!!
The error I am getting is "Unable to determine the workspace. You may be able to correct this by running 'tf workspaces /collection:TeamProjectCollectionUrl'"
But as can be seen I am already specifying the workspace in the batch file.
Any ideas why these commands work from the Windows command line but fail from TeamCity? How do I get them to run from TeamCity?
The solution in my case was to upgrade my Team Foundation Client from 2012 to 2013. There are known timeout issues with the 2012 version and upgrading to 2013 has resolved these.
I had the same issue (TeamCity builds that fetched code from TFS would get stuck indefinitely at the Updating sources stage, blocking the agent).
The solution for me was to make sure that the TeamCity Build Agent ran under the same service account as the TeamCity Server. The server would be able to access the TFS project and instruct the agent to do a build, but the agent itself got stuck when it was not authorized.
When that account mismatch was fixed, it all started working as it should.
As a side note, when the parameter “teamcity.tfs.mode=java” is set, the TeamCity agent does not get stuck, but instead fails with an instructive error message (detailing the current service account name), if it runs under an unauthorized account.
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
I have a VS2010 TFS Build server configured with a build definition set for continuous configuration.
For my BizTalk 2010 solution I have 200+ tests. These tests all run ok on my dev box but on the build server, for the tests dealing with flat-files, I get the error "Unable to find Microsoft.BizTalk.Tom.resources". My guess is that this is a resource file contained within the assembly Microsoft.BizTalk.TOM.dll Although I've used reflector and can't see the resources.
It turns out Microsoft.BizTalk.TOM.dll is a .Net 2 dll that is installed with BizTalk into the following folder:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies
I've checked the build server and confirmed that this assembly is present, in the above folder.
I have tried the following, based on 3 different blog postings around the same issue:
Included a reference to dll and set copylocal to true
Added the assembly to the .Net 2 GAC
Added the assembly to the "Additional files to deploy" list from the Test Settings dialog / Deployment tab
Added the assembly to the "Folders to use when tests are run" list from the Test Settings dialog / Unit Test tab
After the tests fail I check the \TestResults\Out folder. I can see that the Microsoft.BizTalk.TOM.dll has been copied here.
When I check the equivalent folder on the dev server I don't see any files that aren't present on the build server.
Any ideas what I can try next please?
I found a copy of the Microsoft.BizTalk.Tom.dll in the folder: C:\Users\tfs_service\AppData\Local\assembly\dl3\randomname\
After researching, it turns out this is where "Shadow Copies"of assemblies are stored: what is cache AppData\Local\assembly\dl3?
I would like it know why shadow copies are being made and how I can prevent it, I guess in my case the app domain is MsTest?
I deleted the shadow copies and uninstalled from the GAC, so that I was left with copies in only the following folders:
C:\Program Files (x86)\Microsoft Visual Studio
10.0\Common7\IDE\PublicAssemblies
C:\Program Files (x86)\Common Files\Microsoft BizTalk
After deleting the shadow copies and and restarting the server, the tests now run successfully.
Consider a .csproj containing the following directive:
< Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
There's a standalone TFS Build service installed on a machine, with a default Controller and one Agent. The TFS components were installed; Visual Studio was not installed.
When compiling an ASP.NET MVC 2 Web Application (targeting .NET 4), the TFS Build service encounters an error:
C:\somepath\foo.csproj (219): The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
TF270015: 'MSBuild.exe' returned an unexpected exit code. Expected '0'; actual '1'.
It's true: there's no sub-directory "WebApplications" in the "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0" directory.
It seems that this subset wasn't included in the install of the TFS Build service. TFS doesn't give any options on what pieces are installed for Build service.
What's the most appropriate way to install these artifacts, and any dependencies, on this TFS Build machine? Could this have been avoided?
Have you tried creating the path C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\ manually and copying the file Microsoft.WebApplication.targets there? If Microsoft.WebApplication.targets doesn't contain references to some specific build tasks that should do the trick.
At least that worked for Visual Studio 2005.
Check for unwanted references like 'stdole.dll' in your references and remove it.
connect to tfs again (to refresh)
try to build again.
Best solution is to always install VS2010 on your build machine.