Asked  8 Months ago    Answers:  5   Viewed   186 times

As part of our ASP.NET Core 2.0 build process I have added a dotnet test command which I have added as a Windows batch file.

Here is my command.

dotnet test "MyProject.csproj" --no-restore --results-directory "MyProjectTestResults" --verbosity minimal

And here is the output when run from the command line.

So it all appears to work correctly, yet no test results / test output is created.

 Answers

4

To output the test results from dotnet test, you can try pass -xml /some/path/out.xml or use the work parameter, like this: dotnet test --work:"mypath/myresult.xml". See below threads for details:

  • dotnet test - Output test results
  • Is there a way to specify TestResult.xml location?

Besides, generally you need to specify the argument -l|--logger <LoggerUri/FriendlyName> which specifies a logger for test results.

e.g.:

dotnet test "myproject.csproj" --logger "trx;LogFileName=pathtotestsfolderresults.trx" or dotnet test "myproject.csproj" -l:"trx;LogFileName=pathtotestsfolderresults.trx"

To make the generated trx files available as test results in VSTS/TFS, you can use the "Publish Test Results" task:

Sunday, September 26, 2021
 
5

What am I doing wrong? Can someone correct my command?

It`s depends on the version of your cli.

If you are using the 2.0 version of cli, then you can use dotnet publish command on a windows machine and it would work.

dotnet build WebApplicationDeploy.sln /nologo /p:PublishProfile=Release /p:PackageLocation="C:SomePathpackage" /p:OutDir="C:SomePathout" /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /maxcpucount:1 /p:platform="Any CPU" /p:configuration="Release" /p:DesktopBuildPackageLocation="C:SomePathpackagepackage.zip"

But if you are using 1.0.4 version of the cli, then you should use the msbuild version of the command (The ability to call dotnet build was added in 2.0 cli).

msbuild WebApplicationDeploy.sln /nologo /p:PublishProfile=Release /p:PackageLocation="C:SomePathpackage" /p:OutDir="C:SomePathout" /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /maxcpucount:1 /p:platform="Any CPU" /p:configuration="Release" /p:DesktopBuildPackageLocation="C:SomePathpackagepackage.zip"

For the detail info, you can refer to the same issue on GitHub.

Friday, July 30, 2021
 
godot
 
4

You can see all the dotnet test options by executing dotnet test --help. One of the options is -l, --logger, which gives some great information:

Specify a logger for test results.
Examples:
Log in trx format using a unqiue file name: --logger trx
Log in trx format using the specified file name: --logger "trx;LogFileName=<TestResults.trx>"
More info on logger arguments support:https://aka.ms/vstest-report

That support link https://aka.ms/vstest-report, has the full information.

So to answer your specific question, you can say

dotnet test -l:trx;LogFileName=C:tempTestOutput.xml

To publish the results to a particular directory.

Another option is setting MSBuild properties in your test.csproj:

<PropertyGroup>
  <VSTestLogger>trx</VSTestLogger>
  <VSTestResultsDirectory>C:temp</VSTestResultsDirectory>
</PropertyGroup>

Which tells the logger to put the file in the C:temp directory.

Tuesday, September 7, 2021
 
Rob13
 
2

If you published the same application targeting netcoreapp1.0 first and then you the net4x version then I think it is a bug in Web Deploy. I hit a similar problem when publishing to Azure - https://github.com/aspnet/Hosting/issues/801#issuecomment-227920473. I fixed it by first manually deleting all the contents in the target folder and then publishing the application targeting net4x again (https://github.com/aspnet/Hosting/issues/801#issuecomment-228123238). I think Web Deploy leaves some dlls behind or does not update if the names are the same and they are then picked up but fail because they are not matching the target framework and their dependencies are missing. I also found that checking the checkbox in Web Deploy to delete files at the destination did not fix the problem and opened an issue on that.

Saturday, October 16, 2021
 
2

Credit to Jesse Houwing for helping me on this one. I had to detach and reattach the Team Project Collection using the TFS Admin Console on the App Server. It seems there is an issue with Update 1 (or perhaps one of the Release Candidates).

For those with the same problem, it will obviously take TFS offline but it took less than 5 minutes.

Tuesday, November 23, 2021
 
Ikarus
 
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :
 
Share