I am trying to run Nunit Test using Visual Studio test Runner from XAML build in TFS,but i am getting error saying
TF900547: The directory containing the assemblies for the Visual Studio Test Runner is not valid ''.
Based on your history, I assume you are using VSTS, you can refer to these steps to run Nunit test:
Create a unit test project via VS
Install NUnit and NUnit3TestAdapter packages
Add solution to source control (if the package files not added to the source control, you can refer to the steps below)
Open Source Control Explorer in VS
Add a new folder (e.g. Tools) and add Nuget.exe to the source control
Add bat file to your test project (For example: Tools\nuget35.exe restore NUTest2\NUTest2.sln)
Open XAML build definition and map Tools source folder to agent
Select Process section
Choose TfvcTemplate.12.xaml build template
In the Advance section of Build, specify Pre-build script path with previous bat file.
Related
I have set up a build definition on VSTS. It builds fine on my local machine. But I get the following error when I start the build process
[error]Dotnet command failed with non-zero exit code on the following projects : D:\a\1\s\My.Project\My.Project.csproj
Check the project name in the error carefully. Chances are its not actually in your solution .sln ... and wouldn't build if it were. By default, VSTS will try to build all .csproj files regardless whether they are in your solution or not. Remove all .csproj files for projects you don't want to be built.
In my case. I deleted the \My.Project directory (which contained the .csproj file) and the build suceeded.
edit your.csproj and add MvcRazorCompileOnPublish as false
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
<PreserveCompilationContext>true</PreserveCompilationContext>
<MvcRazorCompileOnPublish>false</MvcRazorCompileOnPublish>
</PropertyGroup>
views will be included in publish without the VSTS build failure.
In my case, my project had the line <IsPackable>false</IsPackable> in the csproj file, which caused the Pipeline job to fail in DevOps when it tried to create a package.
I faced similar issue with my automation code's Build pipeline with CI. I was using ".Net Core" task for test execution.
Solution:
I switched my "test" execution task from .Net Core to "Visual Studio test".
In VSTest task under "Test files" i specified exact project name which contains Test Cases. Instead of main solution.dll. As shown in image.
I'm trying to analyze VS solution via Ndepend as part of a tfs build.
I added an .ndproj file in the same directory of .sln file under Sources folder.
I'm Using Team Build 2010 workflow activity to add Ndepend as part of the build.
But I encountred this problem :
There is no application assembly defined in the project file
Can any one help me please.
I have a Visual Studio 2012 C++ solution generated using CMake in which I use google test for unit tests. This works mostly fine, but in one of my tests I want to read a settings file from a local directory. To find the file I copy the file as a post build step from my source code tree to the build and install directory using the following CMake commands:
install(FILES ./adapters/settingFile.txt DESTINATION .)
add_custom_command(TARGET testAdapters POST_BUILD
COMMAND "${CMAKE_COMMAND}" -E copy
"${CMAKE_CURRENT_SOURCE_DIR}/adapters/settingFile.txt"
"${CMAKE_CURRENT_BINARY_DIR}"
COMMENT "Copying elastix parameter files")
This works fine: after building my test the settingFile.txt is in the same location as the testAdapters.exe. Using a right click on the testAdapters project and starting a Debug session also works find.
However if I choose to run the test from within the "Test Explorer" window, either by "Run All" or by right clicking the test and choosing "Run selected tests", the test cannot find settingsFile.txt. By right clicking and choosing "Debug selected tests" I found that running the test from the "Test Explorer" the working directory defaults to the visual studio program directory: C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE. I can think of several possible solutions, but don't know how to achieve this:
Set the working directory for the "Test Explorer"
Set the working directory for each test executable
Set the working directory for all google tests
Using CMake set some define that points to a user specified location and use that in the test code. (I consider this a rather ugly solution)
I need a solution that is platform independent. Does anyone know how to achieve (1) or (2) or do you know of a better solution?
With the current version 0.12.3 of GTA you can at least achieve (1):
Tools
Options
Google Test Adapter (or use Search Options)
General
Working directory (at the bottom)
Unfortunately GTA seems to only support $(ExecutableDir) (the default) and $(SolutionDir). It seems that GTA cannot tell which project is the unit test project, so it is not possible to use the project directory as a start directory.
Is there a way to set breakpoints and step through them using NUnit with a mixed project of native C++ and managed C++?
I have my SUT (Software Under Test) configured as a static library (native C++)
I have my unit test suite as a separate project configured as a dll that depends on my previously stated library. I also added said library as a reference to my unit test project.
My tests run fine in NUnit, breakpoints just don't work.
Again, is there a way to get the breakpoints to work with NUnit with Native/Managed C++?
The most convenient way to do this is to set up a custom tool entry specifying the path to NUnit as the command. For a VS2003 C# project, you can use $(TargetPath) for the arguments and $(TargetDir) for the initial directory.
With Visual Studio VS2005 this becomes a bit harder, because that release changed the meaning of the 'Target' macros so they now point to the intermediate 'obj' directories rather than the final output in one of the 'bin' directories. Here are some alternatives that work in both versions:
$(ProjectDir)$(ProjectFileName) to open the VS Project rather than the assembly. If you use this approach, be sure to rename your config file accordingly and put it in the same directory as the VS project file.
$(ProjectDir)bin/Debug/$(TargetName)$(TargetExt) to run the assembly directly. Note that this requires hard-coding part of the path, including the configuration.
If you would like to debug your tests, use the Visual Studio Debug | Processes… menu item to attach to NUnit after starting it and set breakpoints in your test code as desired before running the tests.
I am using MSBuild in my TFS Buildprocess using the DefaultTemplate to build multiple configurations(Debug/Release) of the same solution. When I build only release or only debug the unit tests are run but when I run the build with both configurations the unit tests are not run.
When I am running multiple configurations I have each of them Defined in the build definition under Process-> Items to Build-> Configurations to Build which is Mixed Platforms|Release,Mixed Platforms|Debug. When I run a single configuration I am using Mixed Platforms|Release or Mixed Platforms|Debug.
I am unable to put the entire log here(It is over 6000 lines long) but it appears that it isnt finding any of the testAssemblies.
Edit:
Here are the actual sections of the log. I'm not sure where Mixed Platforms\Release is coming from in the searchpathroot.
I should also add that we compile into our Source's folder because a few of our scripts only work in that layout.
Debug Only(works)
Run MSTest for Test Assemblies
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe /nologo /usestderr /testSettings:"C:\Builds\6\ProductName\BuildName\Sources\Product\Local.testsettings" /searchpathroot:"C:\Builds\6\ProductName\BuildName\Sources" /resultsfileroot:"C:\Builds\6\ProductName\BuildName\TestResults" /testcontainer:"C:\Builds\6\ProductName\BuildName\Sources\Test\UnitTestCommon\bin\Debug\UnitTestCommon.dll" /testcontainer:"C:\Builds\6\ProductName\BuildName\Sources\Test\UnitTestCommon\bin\Release\UnitTestCommon.dll" /testcontainer:"C:\Builds\6\ProductName\BuildName\Sources\Test\UnitTestWCF\bin\Debug\UnitTestWCF.dll" /testcontainer:"C:\Builds\6\ProductName\BuildName\Sources\Test\UnitTestWCF\bin\Release\UnitTestWCF.dll" /publish:"http://dctfs2010.company.dc:8080/tfs/Product" /publishbuild:"vstfs:///Build/Build/964" /teamproject:"ProductName" /platform:"Mixed Platforms" /flavor:"Debug"
Loading C:\Builds\6\ProductName\BuildName\Sources\Product\Local.testsettings...
Loading C:\Builds\6\ProductName\BuildName\Sources\Test\UnitTestCommon\bin\Debug\UnitTestCommon.dll...
Loading C:\Builds\6\ProductName\BuildName\Sources\Test\UnitTestCommon\bin\Release\UnitTestCommon.dll...
Debug and Release(Does not work)
Run MSTest for Test Assemblies
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe /nologo /usestderr /testSettings:"C:\Builds\6\ProductName\BuildName\Sources\Product\Local.testsettings" /searchpathroot:"C:\Builds\6\ProductName\BuildName\Sources\Mixed Platforms\Release" /resultsfileroot:"C:\Builds\6\ProductName\BuildName\TestResults" /testcontainer:"C:\Builds\6\ProductName\BuildName\Sources\Test\UnitTestCommon\bin\Debug\UnitTestCommon.dll" /testcontainer:"C:\Builds\6\ProductName\BuildName\Sources\Test\UnitTestCommon\bin\Release\UnitTestCommon.dll" /testcontainer:"C:\Builds\6\ProductName\BuildName\Sources\Test\UnitTestWCF\bin\Debug\UnitTestWCF.dll" /testcontainer:"C:\Builds\6\ProductName\BuildName\Sources\Test\UnitTestWCF\bin\Release\UnitTestWCF.dll" /publish:"http://dctfs2010.company.dc:8080/tfs/Product" /publishbuild:"vstfs:///Build/Build/962" /teamproject:"ProductName" /platform:"Mixed Platforms" /flavor:"Release"
Directory "C:\Builds\6\ProductName\BuildName\Sources\Mixed Platforms\Release" not found.
If you click on the properties of your solution (the solution that you build as part of your build). You will have configuration manager. At the configuration manager you will be able to see 'Debug', 'Released', 'Mixed', etc any other configurations you may have defined. Can you see the test project checked to be build in the mixed configuration? If this is not being build, the test.dll will not be available which means, MSBuild will not have any tests to run.
Another way to verify why the tests are not running, is to look at the build drop directory and see if you can see the test.dll there. If the test.dll is not there then the problem is with how you have the projects configured in the configuration manager.
Turns out my outputDirectory was setup wrong for how our projects are compiled. Which is where the searchpathroot problem came from.