I've created a SpecFlow project and I can run its tests from Test Explorer in Visual Studio.
I've added this to App.config:
<specflow>
<unitTestProvider name="MSTest"/>
</specflow>
But when I try to run them from the command line using mstest, it can't find any tests to execute:
c:\Workspace\Test>mstest /testcontainer:SpecFlow.Tests\bin\Debug\SpecFlow.Tests.dll
Microsoft (R) Test Execution Command Line Tool Version 15.0.26208.0
Copyright (c) Microsoft Corporation. All rights reserved.
Loading SpecFlow.Tests\bin\Debug\SpecFlow.Tests.dll...
Starting execution...
No tests to execute.
Any idea what's wrong with my command line?
Try passing an absolute path to the /testcontainer parameter
c:\Workspace\Test>mstest /testcontainer:c:\Workspace\Test\SpecFlow.Tests\bin\Debug\SpecFlow.Tests.dll
vstest.console.exe can run all types of tests even with console.
"C:\Program Files (x86)\Microsoft Visual Studio\2017\TestAgent\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" %PROJECT_NAME%.Tests.dll'
was the solution for me
Related
I might be missing something really simple here. I'm trying to build a solution in Teamcity using msbuild but it always keeps failing with the below error.
'msbuild' is not recognized as an internal or external command,
operable program or batch file.
I have VS2017 installed and when I run the solution locally through command line on the same Teamcity agent, it works perfectly with the following comments.
Microsoft (R) Build Engine version 15.4.8.50001 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
But for some reason it always fails on teamcity. I'm at a loss as to what am I missing here. Any pointers are greatly appreciated.
Following is the command that I'm using to compile the solution
msbuild hello.sln /t:Rebuild
msbuild fails in Teamcity
Agree with stijn. According to the error log, it seems MSBuild not in the default path, so it could not be found.
To resolve this issue, you should make sure you have installed the Visual Studio 2017 or Microsoft Build Tools on the teamcity agent and need to properly configure your build runner, especially MSBuild version.
Besides, you can also try to create environment variable "MSBuild" and set it to the path of MSBuild.exe in your teamcity agent.
The default path of MSBuild for Visual Studio 2017 is:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin
If above not help you, please share us your configuration about Build Runner.
OS: Microsoft Windows [Version 10.0.14393]
VS-Version: 2017 Community
When I run vswhere.exe I get the following back and based on on the official vswhere documentation I can build the path to msbuild and this seems to work:
C:\Users\user\Desktop>"C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe"
Visual Studio Locator version 1.0.62 [query version 1.10.80.60812]
Copyright (C) Microsoft Corporation. All rights reserved.
[...]
installationPath: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community
[...]
C:\Users\user\Desktop>"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe"
Microsoft (R)-Buildmodul, Version 15.1.1012.6693
If I start the developer command prompt located in "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsMSBuildCmd.bat" I get the following result:
C:\Users\user>"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsMSBuildCmd.bat"
**********************************************************************
** Visual Studio 2017 MSBuild Command Prompt
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
C:\Users\user>where msbuild
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
Why and what is the second path returned after starting the developer command prompt
I always use the first path ("C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe") to call msbuild for building C/C++/VC++ Projects. Is this in someway wrong?
VS 2017 switched to local copies of msbuild, if you used a VS 2015 command prompt, you would see a different global path.
The where command lists all the matching executable files that it finds on the PATH, but only the first one will be used by the command prompt when you run an msbuild command.
The second msbuild.exe you see is part of the .NET Framework - this is the version of MSBuild that was integrated into and shipped as part of the .NET Framework. This version is old compared to the ones installed by recent versions of Visual Studio. But it will likely be continued to be included in .NET Framework for compatibility reasons. It is even able to build a lot of projects that will then use the targets and tasks installed by VS - only project format changes that required changes to MSBuild itself will be incompatible (like the new project format used for .NET Core projects).
You should always use the VS 2017 version of msbuild.exe to always get build results consistent with visual studio.
I have an existing XAML build I am porting over to Visual Studio Team Services build. There is a Solution file that contains two wixproj projects, and this builds with no issues on the current (legacy XAML) Hosted Build Controller (which uses WiX Toolset v3.7).
In VS TS, I created a new build process and added a step to Build solution using a Visual Studio Build step. I have set the Solution path to my sln that contains the two wixproj projects. All the other options are the defaults except the timeout which is set to 10 minutes.
The build step initiates but times out after calling the Light.exe step, as in the log below:
PrepareForBuild:
Creating directory "obj\Debug\".
Creating directory "bin\Debug\".
Compile:
C:\Program Files (x86)\WiX Toolset v3.10\bin\candle.exe -dDebug ...
Windows Installer XML Toolset Compiler version 3.10.3.3007
Copyright (c) .NET Foundation and contributors. All rights reserved.
{myfile}.wxs
Link:
C:\Program Files (x86)\WiX Toolset v3.10\bin\Light.exe -out ...
Windows Installer XML Toolset Linker version 3.10.3.3007
Copyright (c) .NET Foundation and contributors. All rights reserved.
##[error]The task has timed out.
The build will run 10 minutes and then throw a timeout error. It usually takes ~1 minute to finish. There is no information in the log about where this may be timing out or why.
I see that VS TS Build uses WiX version 3.10, but WiX version 3.10 works for me locally to build this same sln. I haveve tried all options for Visual Studio Version in the build step with same results.
Any ideas what I am missing and why this isn't working?
I found a post in the wixtoolset GitHub project documenting a bug in WiX 3.10 about deadlocks occurring with WiX projects if there are any warning or error messages generated during the build.
The workaround is to add the following MSBuild Arguments in the build step:
/p:RunWixToolsOutOfProc=true
This resolved my issue with the Light.exe process timing out.
Files (x86)\WiX Toolset v3.10\bin\candle.exe -dDebug ...
Windows Installer XML Toolset Compiler version 3.10.3.3007
Copyright (c) .NET Foundation and contributors. All rights reserved.
{myfile}.wxs
Link:
C:\Program Files (x86)\WiX Toolset v3.10\bin\Light.exe -out ...
Windows Installer XML Toolset
I have class library project which reads word document files. and I have created 30 unit cases scenarios for it. When I run the unit test using visual studio IDE it runs perfectly and all the test cases get "Success", However when I use Visual Studio Command Prompt and test it, some of the test cases get failed. I would appreciate if you guys can provide me some hint in this regard.
To test my solution in Command Prompts I type: "MSTest /testcontainer:mysolutiontest.dll"
If you are running VS2012 or later, use vstest.console.exe:
"C:\Program Files (x86)\Microsoft Visual Studio
12.0\Common7\ide\CommonExtensions\Microsoft\TestWindow\vstest.console.exe"
PathToYour.dll /logger:trx
You'll also probably want to use a .runsettings file to specify the TargetPlatform and ResultsDirectory, which would then use a command line like this:
"C:\Program Files (x86)\Microsoft Visual Studio
12.0\Common7\ide\CommonExtensions\Microsoft\TestWindow\vstest.console.exe"
PathToYour.dll /logger:trx
/settings:PathToYour.runsettings
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.