After upgrading both Team Foundation Server and Visual Studio from 2013 update 4 to 2015, i created a build in the new build system.
The build includes only two steps: One Visual Studio Build step and one Visual Studio Test step. There's only one single simple solution with a class library project and a test project.
The Build step runs fine. The Test step does nothing. It just says
Starting test execution, please wait...
but the test are not running.
When i edit the VS Test step in the build definition and set the VSTest version to "Visual Studio 2013" instead of "Visual Studio 2015", everything works fine and it outputs as expected:
Starting test execution, please wait...
Passed <nameoftest1>
Passed <nameoftest2>
Passed <nameoftest3>
Passed <nameoftest4>
etc
I found out that during that build step, the following line gets executed:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe "C:\pathToTestDll\TestProject.dll
So i tried to run this from commandline on my own pc, and found out that when i use vstest.console.exe from the Visual Studio 12.0 folder, everything works fine, but when i use vstest.console from the Visual Studio 14.0 folder, the tests are not running.
I also found out that when i run the command prompt as administrator, it runs all the tests with vstest.console from the Visual Studio 14.0 folder.
Has anybody also had this issue, or is there a way to run the whole build (or just the test step) with elevated rights, so i can run my tests with the VSTest Version set to Visual Studio 2015?
Related
Environment is
1. Visual Studio 2017
2. Visual Studio Team server
In My requirement is, If i update "TEST SCRIPTS" code in Visual Studio Team server its will build automatically every release. But i need to to RUN the updated "TEST SCRIPTS" in Visual Studio Team server.
There are many tasks to run test, such as Visual Studio Test, Maven Test, Run Functional Test. So you can create a unit test/coded UI test project in VS 2017 and run the test through Visual Studio Test task.
Related article: Get started with continuous testing.
I recommend you run the test during the build.
Regarding run the test once the Test Script code be changed, you can setup a CI build (Triggers tab). If you want to do test in release, you need to publish artifact (test project build result), and configure release with Continuous Deployment mode (Triggers)
When I run my xunit tests from VS 2017 the working directory is different than it was in VS 2015 and what's even more ugly - it's different for just executing a test and debugging one.
In execute mode its like UnitTestProject\bin\debug\netcoreapp1.1
In debug - C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\
When I run dotnet test from within my project folder it's just UnitTestProject
I prefer the latter and that's actually how it was in VS 2015 - it was always project directory in all three cases.
So the question is how to make VS 2017 (and dotnet test unless there's a new way now) to use the same working dir.
We have a build definition in TFS 2015 that have worked fine with Visual Studio 2015 projects and solutions. We have now decided to upgrade to Visual Studio 2017 and thus we would like to target Visual Studio 2017 in the Visual Studio build task. We have installed Visual Studio 2017 on the build agent. Unfortunately the only options available int the Visual Studio build task are 2012, 2013, 2015 and Latest. We have tried latest but it does not find Visual Studio 2017 on the build agent. It won't work with the msbuild task either.
I have a similiar issue and resolved by installing VS2017 in my build agent server and configuring MSBuild to point to my MSBuild 15.0 folder:
Add MSBuild to your build steps
On the Advanced options, expand and fill the 'Path to MSBuild' like the image below:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin
VS2017 RTM is released recently while TFS2015 was released before. That's why there is no VS2017 option in VS Build Task in TFS2015 Server. If you upgrade your server to the latest TFS2017, you would see "Visual Studio "15" (preview)" option listed in VS Build Task which is the version for VS2017 preview. And in the feature, the option will be updated to VS2017 which is the same as VSTS.
we are facing a similar issue and it is not possible for us to update ourselves as it is maintained on a company level where we cannot take that much influence.
However our team wanted to switch to VS2017 and make use of the C# 7 features. That's why we tried it as well with replacing the build steps from Visual Studio Build to MSBuild. Sadly this did not work as expected (we got some errors during the build).
As our main objective is to use the C# 7 features we looked for a way how to still achieve that at the time with Visual Studio 2015 remaining on the Build Server. We ended up using the nuget package Microsoft.Net.Compilers that, when used in a project, will use that compiler instead of the installed one.
More on this can be found in this Thread.
It seems the updates to the build tools are installed via the command line of the VS2017 installer.
See the docs for details.
Just adding another thing: if you're using custom build template make sure to edit it and modify the ToolPath attribute value to:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin
I've written a c# program that builds *.csproj and *.vcxproj using Microsoft.Build.Evaluation. It works great on both project types if I compile and run it from inside Visual Studio 12. But if I run the exe directly (outside of Visual Studio) I get the example error message below. The error occurs only for vcx projects; c# projects continue to build just fine
Question: Why am I getting this error? Why does my program work fine for both C# and vcx projects when run from within VS12, but fails, but only for vcx projects, when run outside of VS12?
Please don't chastise me for not using MSBuild.exe. My orders were to programmatically build C# and vcx projects using Microsoft.Build.Evaluation.
Code:
using Microsoft.Build.Evaluation;
...
Project proj = new Project("MyCppProject.vcxproj");
proj.Build(logger);
Runtime Error:
Building MyCppProject
Project "MyCppProject.vcxproj" (default targets):
VCMessage:
ERROR C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(518,5): Specified platform toolset (v110) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected.
Done building project "MyCppProject" -- FAILED.
One solution is to force the Visual Studio version as an environment variable prior to loading and building the project:
using Microsoft.Build.Evaluation;
...
Environment.SetEnvironmentVariable("VisualStudioVersion", "11.0")
Project proj = new Project("MyCppProject.vcxproj");
proj.Build(logger);
Visual studio maintains platform tool sets list supported for the version of Visual studio you are currently running for example on my machine I have VS 2008, 2010 and 2012
Now suppose when I install Visual Studio 2013 which has a Platform Toolset version of V120. What happens, is that the project saves this in its corresponding XML files in the format (vcproj, vcxproj, vcxproj.filter.user files).
now this valus is not known to VS 2012 so it complains when opened in VS 2012.
Similarly for opening VS 2012 project in VS 2010, as in your case and so on.
Solution:
To fix this issue, Open you solution file in notepad++.
Make these 2 changes
1) Replace
Format Version 12.00
with
Format Version 11.00
2) Replace
Visual Studio 2012
with
Visual Studio 2010
Then open the file again in visual studio and rebuild solution.
I have a mstest project that uses Microsoft fake assembly. The test methods are executing fine in my local Visual studio ultimate. I never check in the fake dll in to repository (SVN), assuming that it will be created in the build server (Jenkins). Later I understood that the build server is using MSBuild.exe to build the solution and since MSBuild.exe doesn't know how to create the fake assembly, the build seems failing. Installing the Visual studio ultimate in the build server is the only one option or is there any other ways to execute the unit test (like check in the fake dll in to repository).
You need Visual Studio Ultimate or Visual Studio Premium (if you are using a version later than Visual Studio 2012 Update 2) to be able to generate fakes. Also please make sure that your build script is using vstest.console.exe to execute tests. Fakes is not supported by MSTest.exe