MSBuild to NUnit transform (VS2010) - visual-studio-2010

I tried to use the xslt mentioned in this SO question to turn MSTest trx into NUnit Xml (to get round a bug with MStest output in Bamboo) but seem to have no joy.
Is the trx format different for VS2010 ? (or is it just me?)

The namespace has changed. Just replace
xmlns:t="http://microsoft.com/schemas/VisualStudio/TeamTest/2006"
with
xmlns:t="http://microsoft.com/schemas/VisualStudio/TeamTest/2010"
and it should work.

Related

XUnit Tests No Longer Working After Upgrade From .NET 5 To .NET 6 (Q & A)

I have an xUnit unit testing project. All was working fine in .NET 5.
In Visual Studio 2022, I changed the .NET Version in the csproj to .NET 6 as shown below.
Following this, the tests build but no longer run.
There is no info in the output window. The Test Explorer just says it wont run the tests, with 'unexpected error detected'.
What should I do to fix this?
I created a new project and compared the csproj file with my old project. There were a couple of differences
First, I needed to add the nuget package for Microsoft.NET.Test.Sdk (in my case, version 16.11.0). This seemed to fix it.
I also noticed a couple of properties in the first PropertyGroup that I was missing. I added those too. However, just adding Microsoft.NET.Test.Sdk fixed it for me.
In my case I was changing from NUnit to XUnit and also needed to add the xunit.runner.visualstudio nuget package

Go To Test (F12) doesn't work in Test Explorer in Visual Studio

When I click on Go To Test or use F12, nothing happens. This happens for SpecFlow tests in VS2019. This is an issue because it is difficult to manually find the test in the *.feature file.
Is there any way for me to make it start working again?
P.S. I found a similar issue described in https://github.com/SpecFlowOSS/SpecFlow/issues/1457
Edit: I am using VS2019 16.8.5, .NET Framework 4.8, my csproj uses the old XML format, and I am using a SpecFlow feature where *.feature.cs are not under source control.
<Import Project="..\packages\SpecFlow.Tools.MsBuild.Generation.3.0.225\build\SpecFlow.Tools.MsBuild.Generation.targets" Condition="Exists('..\packages\SpecFlow.Tools.MsBuild.Generation.3.0.225\build\SpecFlow.Tools.MsBuild.Generation.targets')" />
<Import Project="..\packages\SpecFlow.NUnit.3.0.225\build\SpecFlow.NUnit.targets" Condition="Exists('..\packages\SpecFlow.NUnit.3.0.225\build\SpecFlow.NUnit.targets')" />
As you already found out, this is a known issue with the old project format.
There are two possible workarounds for you:
convert to the new sdk format for csproj
Use the SpecFlow+ Runner as unit test runner

Integration between MSTest, Specflow and Serenity

Introduction
After a long struggle i finally found out how to run my specflow scenario's through the MSTest Runner. However i could not find a convenient way of showing the test results in the orderly overview that many BDD books and courses promote.
What i've tried so far
The way i currently generate my reports is with the following CMD commands, executed in the Visual Studio Dev CMD.
generic
"navigate\to\specific\visual\studio\folder\mstest.exe" /testcontainer:"navigate\to\test\dll\relative\to\mstest" /resultsfile:\folder\in\my\project\result.html
"navigate\to\specific\specflow\folder\in\project\specflow.exe mstestexecutionreport "absolute\path\to\my\csproj\file\under\test" /testResult:relative\directory\in\project\testResults.trx /out:directory\relative\in\project\TestResults.html
my specific unreadable (obfuscated) case
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\mstest.exe" /testcontainer:"C:\Workspace\Branch\Sub1\Sub2a\Project\bin\Debug\Project.dll" /resultsfile:\Sub2a\TestResults\TestResults.trx
"C:\Workspace\Branch\Sub1\Sub2b\SpecFlow.2.0.0\tools\specflow.exe" mstestexecutionreport "C:\Workspace\Branch\Sub1\sub2a\Project\Project.csproj" /testResult:Sub1\TestResults\TestResults.trx /out:Sub1\TestResults\TestResults.html
I probably don't have to mention how tighlty coupled this script is to my specific machine, workspace, project, visual studio version and tests.
There must be some way to make these tools work better with a more generic script or some kind of plugin for the mstest report without going through so much cmd line statements with huge parameters.
Thanks in advance.

Excluding standard directories from code coverage results with C++/CLI

I have a Visual Studio 2010 .NET 4 solution with C# projects and a C++/CLI project.
I use Visual Studio's built in unit tests and code coverage.
Other than the fact that Visual Studio 2010 coverage tool for C++/CLI projects seems to be much weaker than Visual Studio 2008 coverage tool, I get weird results.
For example, I get uncovered code in this file:
c:\program files (x86)\microsoft
visual studio 10.0\vc\include\xstring
And some other files in that directory.
I want to exclude this code from coverage results.
Is there a way to put some exclude attributes on that code?
If not, is there a different automatic way to exclude that code from coverage? If not, is there a way to use EXCLUDE option to exclude it? Can it be done automatically within Visual Studio without running the coverage tool from command prompt?
Any other solutions?
Well, the MSDN documentation you linked to says:
EXCLUDE option is supported with code coverage.
To exclude all functions in a namespace use the wildcard character:
MyNamespace::*
Have you tried /EXCLUDE:std::* ? It sounds as if that would be the way to go.

Programmatically build a Visual Studio solution?

Is there a way to programmatically build Visual Studio solutions? E.g. if you are inside a console app, can you programmatically build an existing solution elsewhere?
Sure- MSBuild is included on any machine with .NET 2.0 or better installed. Just call it and pass the solution file, or drive the MSBuild classes (see Microsoft.Build.BuildEngine.Engine) from your code to do it.
devenv.exe solution.sln /build "Release"
You should no longer use the Microsoft.Build.BuildEngine.Engine class. Per MSDN, "This class has been deprecated. Please use Microsoft.Build.Evaluation.ProjectCollection from the Microsoft.Build assembly instead."

Resources