I'm a bit lost and hope someone can help. We used to have a TFS build pipeline, but it has now been upgraded to Azure DevOps TFS. At the same time, new projects need to be put in and we want to have them built and analysed using SonarQube. A load of other things have changed (using .NET 6, so using different MSBuild as well, first Blazor project etc.) and the pipeline isn't working.
I have a pipeline that does:
NuGet restore
dotnet restore
Prepare analysis on SonarQube
Build solution **/*.sln (so I can specify the location for the msbuild.exe)
Run Code Analysis
The first 4 steps run fine, but then on Run Code Analysis it fails after ~45 seconds with an error:
INFO: Importing 34 Roslyn reports
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
INFO: Total time: 42.540s
INFO: Final Memory: 24M/1299M
INFO: ------------------------------------------------------------------------
##[error]ERROR: Error during SonarScanner execution
ERROR: Error during SonarScanner execution
##[error]java.lang.IllegalArgumentException: URI is not absolute
at java.io.File.<init>(File.java:416)
at org.sonarsource.dotnet.shared.sarif.SarifParser10.uriToAbsolutePath(SarifParser10.java:225)
java.lang.IllegalArgumentException: URI is not absolute
at java.io.File.<init>(File.java:416)
at org.sonarsource.dotnet.shared.sarif.SarifParser10.uriToAbsolutePath(SarifParser10.java:225)
[another 80 lines or so of stack trace]
I'm not sure what this is suggesting a fix might be. The step itself doesn't seem to even take a URI, the Project Key/Name that the preparation step has as parameters work okay (testing with a previous pipeline). A Google search has bought up nothing that seems to help.
The only result I found that seemed even vaguely relevant seemed to suggest a fix in the latest version, but TFS only seems to go up to 4.* (4.23.1 specifically) and the latest seems to be 5.* or 6.*
I'm fairly new to all this, so step-by-step low-jargon explanations would be handy, thanks. :)
Related
Ugh....Microsoft have done something.
All our builds that have been kicked off in the last few hours (approx 10:00 GMT) are failing on our "Build Solution step" failing because of the following error (from the logs):
##[error]EXEC(0,0): Error : Error occurred during processing of input file 'XXX.XXX.dll' --> Method not found: 'System.ReadOnlySpan1 Microsoft.IO.Path.GetFileName(System.ReadOnlySpan1<Char>)'.
Does anyone have any ideas on this? Nothing in our codebase has changed.
If you need more information please let me know. Thanks
FYI, this seems to be caused by a recent update to MSBuild (https://github.com/dotnet/msbuild/pull/7680) that has updated the version of System.Memory.
It looks like the obfuscation tool you're using in your build pipeline is built against a previous version of System.Memory and now that the version provided by the MSBuild environment has changed, the obfuscation tool is broken. Most likely requires the obfuscation tool to be updated.
(PS. I'm just relaying the information that others have identified where other tools are having the same issue - see https://github.com/T4MVC/R4MVC/issues/172)
I'm using Azure Pipelines to run automated tests via VSTest Platform (V2). The deployment group I'm using has no Internet access and is private. I have the task currently set up to run Nunit tests in the project via the test assemblies. The deployment group has VSTest Platform installed on it and I specify the path to vstest.console.exe in the task. The build artifact is downloaded from the pipeline.
The error I'm getting during the VSTest task is this:
Unhandled exception ocurred: Microsoft.VisualStudio.Services.WebApi.VssServiceResponseException: Forbidden
Followed by a stack trace and then this shortly after:
Error: The process 'C:\agent\A1\_work\_tasks\VSTest_ef087383-ee5e-42c7-9a53-ab56c98420f9\2.164.2\Modules\DTAExecutionHost.exe' failed with exit code 3762504530
I can attach the full log if need be, but I'm just trying to get some general direction at the moment.
First off, what is VssService? I'm assuming it has something to do with Visual Studio, but the only things I can find with the VSS acronym are Visual SourceSafe (Microsoft source control software from ~2005, so I really doubt that's it) and something to do with Cisco network switches.
Second, what is DTAExecutionHost?
Third, where can I find information on that error code?
I'am trying to create a build pipeline in Azure DevOps which contain a "vs test task". Nothing fancy here. I want to get the code coverage to send it to sonaQube. However, after the pipeline went through the task there is not .Coverage file created.
There is some errors that might be the issue but i'm not sure.
there is a big "Data collection : Could not find data collector 'Code Coverage'", This might be related to the fact that my UnitTestProject.dll is built for Framework 4.6.2 and Platform AnyCPU(for this issue I tried to forced: otherConsoleOptions:/Framework:NETFramework,Version=v4.6.2').
My agent is running on Windows server 2012 and Visual Studio Enterprise everything is up to date:
VS version
[command]"C:\Program Files (x86)\Microsoft VisualStudio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" #C:\Agent_AzureDevOps_1_work_temp\22f8bb11-e53e-11e9-95d5-5bdab8c29281.txt
Microsoft (R) Test Execution Command Line Tool Version 15.9.0
My .trx file is created, however, my .coverage file is nowhere to be seen.
I made sure Code Coverage was Enabled.
My package contain those NuGet
NuGet in my package.config
I'am blocked and don't know where to look anymore if you guys have an idea.
Thanks for the time. If you guys want more information don't hesitate to ask.
I do not have enough reputation to add a comment, so I hope this post will not be deleted (although it is not a direct answer, I think). I wanted to suggest you the following:
Do you have an own *.runsettings file (where you might have specified a specific entry? If you do not specify a *.runsettings file by yourself, the Azure DevOps vstest#2 Task will use a "default" runsettings file. At least this is what I could observe in the log (debug=true)
Hope this helps
BR Michael
I have a similar problem. I run this command :
>dotnet test --logger trx "--collect:Code Coverage"
Determining projects to restore...
All projects are up-to-date for restore.
MyAPI -> ...\MyApi\bin\Debug\net47\MyAPI.exe
MyAPI.Tests -> ...\MyAPI.Tests\bin\Debug\net47\MyAPI.Tests.dll
Warning: Update the Microsoft.NET.Test.Sdk package reference to version 15.8.0 or later to collect code coverage.
Test run for ...\MyAPI.Tests\bin\Debug\net47\MyAPI.Tests.dll (.NETFramework,Version=v4.7)
Microsoft (R) Test Execution Command Line Tool Version 16.10.0
Copyright (c) Microsoft Corporation. All rights reserved.
Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
Data collection : Unable to find a datacollector with friendly name 'Code Coverage'.
Data collection : Could not find data collector 'Code Coverage'
Results File: ...\MyAPI.Tests\TestResults\***_2021-09-03_12_02_21.trx
Passed! - Failed: 0, Passed: 22, Skipped: 0, Total: 22, Duration: 201 ms - MyAPI.Tests.dll (net47)
The .trx is generated, but not the .coverage.
The solution is to add the NuGet package Microsoft.NET.Test.Sdk in the test project.
I have a TFS 2013 RC install running VS 19,12, and 13 on the build agents. I have a build definition using the CopyDirectory action from the toolbox and when I place anything other than a hard-coded path in either the source or destination box, I get this error
The build process failed validation. Details: Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "BuildDetail.DropLocation".'Microsoft.TeamFoundation.Build.Client.BuildDetail' is not accessible in this context because it is 'Friend'.
I have googled this and nothing seems to come up that works.
Any ideas would be great, as we are blocked on using this.
Thanks,
Devin
I believe that you need to use the 2013 build template if you are using the 2013 Build Agent. If you don't want to, or can't, upgrade your template you should reinstall the 2012 build agent which works fine with 2013.
The new templates are on the server, rather than in VC, but you can download them from the build definition screen and check them in if you need to customize them...
So two solutions:
Upgrade your templates to 2013
Downgrade your build agent to 2012 and use the existing templates
I am trying to deploy Visual Studio 2012 SSDT project to Sql Server using TeamCity 8 and MSBuild Publish task but the deployment fails.
When I look at TeamCity logs and use /v:diag switch in my build configuration I see that for unknown reason MSBuild searches for MyProject.sqlproj.publish.sql and for MyProject.sqlproj.dacpac files.
The exact error:
[SqlPublishTask] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets(1233, 5): File "C:\Program Files\TeamCity\buildAgent\work\abf8bc05a2cfe7f\*MyProject*\bin\Debug\*MyProject*.sqlproj.dacpac" does not exist.
The correct .sql and .dacpac files get generated (without the .sqlproj in the middel) in buildAgent/work/identificator/*MySolution*/MyProject/bin/Debug folder.
My TeamCity build step is configured as follows:
Runner type: MSbuild
Build file path: MyProject/*MyProject*.sqlproj
MSBuild version: 4.5
MsBuild ToolsVersion: 4.0
Run platform: 4.0
Targets: Publish
Command line parameters: /p:SqlPublishProfilePath="Debug.publish.xml" /p:Configuration=Debug
If I execute this from commandline I get no errors.
Any ideas on how can I configure TeamCity to search for correct files or configure my project to generate the files that TeamCity is searching for.
Or is my plan to use MSBuild's Publish task futile and I should utilise sqlpackage.exe instead?
UPDATE
After spending almost three days trying to figure this out I gave up and used sqlpackage.exe which works like a charm.
But I would still be interested in an answer though, passing paths to executables in build servers seems a bit crude way to accomplish things.
I had a similar issue and came to the conclusion that the way TeamCity produces "pseudo-project" files with *.teamcity suffixes is confusing something in the MSBuild/SSDT target chain.
I simply replaced the MSBuild runner build step with a pure Command Line step and the problem went away.
We lose the user friendliness of the TeamCity MSBuild runner configuration, but if it works, it's a compromise I'm willing to make.
Note - we are running TeamCity 7 - I am not sure if this has been addressed in later versions.
I found out you can set a System Property named "system.SqlTargetName" on the build configuration to override the default value.
Setting this to your project name without the ".sqlproj" makes the error go away.