MsTest fails when running unit tests as part of CI using TFS 2008 - visual-studio

My configuration:
VS2010 solution
TFS 2008
Build server - TFS 2008
Build server also has VS2008 Team Suite and VS2010 ultimate installed
TFS 2008 builds my VS2010 solution properly. But when it comes time to run the unit tests I get the following MsTest error.
Using "TestToolsTask" task from
assembly "D:\Program Files\Microsoft
Visual Studio
9.0\Common7\IDE\PrivateAssemblies\Microsoft.VisualStudio.QualityTools.MSBuildTasks.dll".
Task "TestToolsTask" Command:
d:\Program Files\Microsoft Visual
Studio 10.0\Common7\IDE\MSTest.exe
/nologo
/searchpathroot:"D:\Builds\App\Source\86\Binaries"
/resultsfileroot:"D:\Builds\App\Source\86\TestResults"
/testcontainer:"D:\Builds\App\Source\86\Binaries\\Tests.dll"
/publish:"http://tfsServer:8080/"
/publishbuild:"vstfs:///Build/Build/26029"
/teamproject:"Proposal" The
"TestToolsTask" task is using
"MSTest.exe" from "d:\Program
Files\Microsoft Visual Studio
10.0\Common7\IDE\MSTest.exe". No platform specified for publish
operation. For switch syntax, type
"MSTest /help"
MSBUILD : warning MSB6006: "MSTest.exe" exited with code 1.
[D:\Builds\App\Source\86\BuildType\TFSBuild.proj]
The previous error was converted to a
warning because the task was called
with ContinueOnError=true. Build
continuing because "ContinueOnError"
on the task "TestToolsTask" is set to
"true". Done executing task
"TestToolsTask" -- FAILED.
I am not sure what is causing MsTest to fail.
Things tried:
- Provided write access to the build folder to the service account that builds the source on the build machine

You can execute a VS2010 build from within TFS2008's MSBuild, but it looks as if it's using Visual Studio 9.0 TestToolsTask (2008) to try to run a Visual Studio 10.0 (2010) test project (MSTest.exe). I'd try tweaking MSBuild to run the TestToolsTask from the "Microsoft Visual Studio 10.0" folder rather than "9.0", so that the entire process is using the same version of the tools. You can override the tools paths in your tfsbuild.proj file's Properties to ensure the correct version of Visual Studio is used to build with - something similar may apply to the test tools.
Alternatively, it's running the VS2010 test tools correctly, but still trying to use a command line that is specific to 2008 - check the settings and see if you can tweak the command line (you may need to override the MS targets files that is running the build if it's a 2008 version). For example in TFS 2010, a lot of command lines changed from using a simple "server:MyServer" to something like "collection:http://MyServer:8080/tfs/MyCollection". You may therefore have to alter the command line to gain full compatibility with the 2010 version of the tool that is now running, even if it still ultimately points at a 2008 server.
My third suggestion (which isn't necessarily very helpful) is to just upgrade to TFS2010 - it's typically a painless install, vastly better than 2008, and will eliminate any difficulties caused by using a hybrid 2008/2010 setup. (If it helps, I was reluctant to upgrade to 2010 because the 2005->2008 upgrade was 8 days of sheer hell. But in comparison the core of the upgrade to 2010 only took a few hours and "just worked" - the install/upgrade process is much improved)

Jason had the correct idea that lead me down to the correct solution.
In my case, I had to update the "Microsoft.TeamFoundation.Build.targets" to point to "Microsoft.TeamFoundation.Build.ProcessComponents.dll" (VS2010 dll) instead of "Microsoft.VisualStudio.QualityTools.MSBuildTasks.dll" (VS2008 dll)
I also had to make sure that the PlatformToBuild was specified in the TfsBuild.proj file.
Once these 2 steps were done, UnitTests were being run as part of the CI build using TFS2008 and a VS2010 solution.
I have blogged about the solution in detail here: http://blog.aggregatedintelligence.com/2011/03/vs2010-tfs-2008-and-unit-tests.html

Related

The "GetReferenceNearestTargetFrameworkTask" task was not found

I have a problem with autocompletion in VS 2017 Community.
Previously I had VS 2017 Enterprise from school, but the key expired so I moved to Community.
Before, everything works great, but now it doesn't work at all.
I found a solution on Stack Overflow here but it doesn't work, so found another solution at GitHub here.
And I got this:
Build FAILED.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(1601,5): error MSB4036:
The "GetReferenceNearestTargetFrameworkTask" task was not found. Check the following:
1.) The name of the task in the project file is the same as the name of the task class.
2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface.
3.) The task is correctly declared with in the project file, or in the *.tasks files located in the
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin" directory.
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.11
Do you know what to do next?
I had the same error message but for a different problem.
So, I'm using MSBuild to automate build/deploy process for Azure Functions. Everything was working fine until I updated both Visual Studio 2017 and Visual Studio Build Tools 2017 at which point I started getting this error. To be precise I got this error only when using MSBuild, building project manually from VS was working fine.
In my case I already had everything set as per #Programmer's answer.
But as I was using MSBuild it turned out that I also had to install NuGet targets and build tasks which are part of Visual Studio Build Tools.
Follow these to fix that error. This applies to VS 2017:
Fix 1:
1.Install Nuget PackageManager from here.
2.Restart Visual Studio.
If the problem is still there, continue below
Fix 2:
1.Download and start/run the Visual Studio Installer again.
2.While the Visual Studio Installer is still running, go to the "Individual Components" tab
3.Tick the "NuGet package manager" check-box that is under "Code tools" option.
4.Click Install to install it.
Screenshot of where this is located:
That should fix the error you see in this question. Restart Visual Studio and test the auto-completion function. If it's not working, see the answers from this question as that is a whole different issue.
I was seeing this issue with msbuild 15.6.82 on a build environment that does not have VisualStudio 2017, only VS Build Tools.
Here's a PowerShell script that resolves this issue, it pretty much does the equivalent of previous answers in the VS Installer, but silently and waiting for completion.
Start-Process "C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installer.exe" -ArgumentList 'modify --installPath "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools" --quiet --add Microsoft.VisualStudio.Component.NuGet.BuildTools --add Microsoft.Net.Component.4.5.TargetingPack --norestart --force' -Wait -PassThru
I'm working with a headless build server on server core, resolved by installing chocolatey package choco install visualstudio2017-workload-webbuildtools from here:
https://chocolatey.org/packages?q=msbuild
I'm reporting an answer from a Microsoft techician
This usually indicates one of two things:
A failed VS installation. If that's the case, I would recommend running a repair on your VS install.
You have msbuild assemblies in the GAC. If that's the case, please ungac them.
Livar Cunha [MSFT]
I got the same problem in Visual Studio 2019, I solved it by simply install unity package

Disable step in Visual Studio Extension build

While I am building own Visual Studio Extension in TeamCity (same applies to any CI server build that supports building VS solutions), my build stucks on the step DeployVsixExtensionFiles. As far as I understand, the target is defined in VS Extensibility files and is being imported into any .csproj by default. I also realize that this is an "aka test" step that tries to embed an extension into a virtual copy of VS via running a command:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe /RootSuffix Exp /ResetSettings General.vssettings /Embedding /Command File.Exit
I have two questions:
1. Should I disable this step for Release build of Extension?
2. If yes, how can this be done.
The VS SDK installs the extension as a part of a build so you can F5 and run it. If you're CI system doesn't care about that, update your CI configuration to pass /p:DeployExtension=false to MSBuild.

VS 2013 and MSBuild

I've recently upgraded to Visual Studio 2013, which has caused back to back problems when building externally using MSBuild (API or Executable with command line args)
Issue #1
When building with MSBuild it doesn't generate Fake assemblies which are required for our Unit Tests, this leads to build failures. A simple build in visual studio fixes this temporarily, until a new fake assembly needs to be generated.
Issue #2
When running code analysis this complains with the following:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\CodeAnalysis\Microsoft.CodeAnalysis.targets(284,5):
error MSB4127: The "CodeAnalysis" task could not be instantiated from the assembly "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\CodeAnalysis\.\FxCopTask.dll".
Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Unable to cast object of type 'Microsoft.Build.Tasks.CodeAnalysis' to type 'Microsoft.Build.Framework.ITask'.
I only have Visual Studio 2013 installed on my machine, apparently installing an older version could fix the issue, but it's not something which I can do. (VS 2013 Ships with its own MSBuild 12.0 which is located in a different directory to the previous MSBuild).
I'm unsure why Visual Studio is behaving any differently to MSBuild, i'm simply pointing to the solution file like so...
msbuild.exe "path\solution.sln" /property:Configuration=Debug
So, Visual Studio 2013 comes with a new version of MSBuild i.e. MSBuild 12.0. Once installed, it changes the path so that the new version is used by default.
Looks like your solution compiles with visual studio 2012, you can either specify the full path to msbuild.exe such as
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild "path\solution.sln" /property:Configuration=Debug
or set the visual studio 2012 environment variables by running the following before executing msbuild
"%VS110COMNTOOLS%"\vsvars32.bat // VS2012 environment variables
EDIT: Using MSbuild 12.0 assemblies "C:\Program Files (x86)\MSBuild\12.0\Bin\" fixes the issue with the code Analysis bug.

use visual studio code coverage as external tool

I would like to leverage visual studio code coverage ability out side Visual Studio as diagnostic test on environment without a Visual Studio instance on it.
I could not grab a tutorial or guideline on how it is done.
So how it can be done?
Even guidelines are good.
In Visual Studio 2012 or newer you can use the vstest.console.exe to invoke tests to gather code coverage. the /enableCodeCoverage commandline switch enables it.
You can gather coverage from a commandline using the older vsperfcmd tool as well. This requires you to have at least a Visual Studio Test Agent installed on the machine. This is no full Visual Studio installation, but it contains teh components required to run tests and gather coverage details.
How to setup the VsPerfCmd tool can be found here in this MSDN post. I copied the steps:
I assume you want code coverage on MyApp.exe
Open Visual studio command prompt
Add %ProgramFiles%\Microsoft Visual Studio 10\Team Tools\Performance Tools to the path
set path=%path%;'%ProgramFiles%\Microsoft Visual Studio 10\Team Tools\Performance Tools'
CD to the folder that contains MyApp.exe
Instrument MyApp.exe for coverage:
vsinstr -coverage MyApp.exe
Start the coverage monitor to collect code coverage data:
vsperfcmd -start:coverage -output:MyApp.coverage
Run the instrumented MyApp.exe:
MyApp.exe
Shut down the monitor once MyApp.exe is done:
vsperfcmd -shutdown
Open the MyApp.coverage file in Visual Studio
With the Test Agent installed on the machine, you can also trigger a test run from Visual Studio (even if it is installed on a different machine).

Solution Converted from Visual Studio 2008 Fails Gacutil Post-Build Steps in Visual Studio 2010

I have converted a .NET 2.0 solution containing multiple projects from Visual Studio 2008 (where everything build correctly) to Visual Studio 2010. I loaded the solution in Visual Studio 2010 running in Admistrator mode and selected "Build Solution". The build failed on some post-build steps in some of the projects:
Microsoft (R) .NET Global Assembly Cache Utility. Version 3.5.30729.1
Copyright (c) Microsoft Corporation. All rights reserved.
Failure adding assembly to the cache: Access denied. You might not have administrative credentials to perform this task. Contact your system administrator for assistance.
36>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.Targets(3717,9): error MSB3073: The command ""C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\gacutil.exe" /i MyAssembly.dll" exited with code 1.
If I select these same projects, and build just the individual project, rather than the entire solution, then the gacutil command is successful.
The error message makes it sound as if permissions are the problem ("Access denied") but I have verified that Visual Studio 2010 is running in Administrator mode -- I see it in the title bar ("MySolution - Microsoft Visual Studio (Administrator)").
Why would gacutil fail when building the entire solution but succeed when just a single project in the solution is built?
I recently encountered the exact same problem after converting one of our solutions to Visual Studio 2010.
Analysis has demonstrated that if two consecutively compiled projects invoke gacutil in their post-build steps, and the second project is small enough, and the build machine is fast enough, then the second invocation of gacutil would systematically fail with an "Access denied" error.
That looked like a race condition of some sort, but we could not determine the exact root cause. Blocking the post-build steps with a busy loop while there was an instance of gacutil running did not change the situation.
In the end, we were able to solve the issue by using version 4.0 of gacutil instead of version 3.5. We changed all calls in our post-build steps from:
"$(FrameworkSDKDir)Bin\gacutil.exe" /if "$(TargetPath)" /nologo
To:
"$(FrameworkSDKDir)Bin\NETFX 4.0 Tools\gacutil.exe" /if "$(TargetPath)" /nologo
After applying these changes, gacutil did not fail again during builds.

Resources