I'm using SonarQube 5.2 and MSBuild.SonarQube.Runner to analyze a solution containing a number of C# projects. When the runner encounters auto-generated files like...
bin\Release\.NETFramework,Version=v4.5.AssemblyAttributes.cs
bin\Release\.NETPortable,Version=v4.5,Profile=Profile7.AssemblyAttributes.cs
...it fails with the following error...
ERROR: Error during Sonar runner execution
org.sonar.runner.impl.RunnerException: Unable to execute Sonar
at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:91)
at org.sonar.runner.impl.BatchLauncher$1.run(BatchLauncher.java:75)
at java.security.AccessController.doPrivileged(Native Method)
at org.sonar.runner.impl.BatchLauncher.doExecute(BatchLauncher.java:69)
at org.sonar.runner.impl.BatchLauncher.execute(BatchLauncher.java:50)
at org.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:102)
at org.sonar.runner.api.Runner.execute(Runner.java:100)
at org.sonar.runner.Main.executeTask(Main.java:70)
at org.sonar.runner.Main.execute(Main.java:59)
at org.sonar.runner.Main.main(Main.java:53)
Caused by: java.lang.IllegalStateException: The folder 'C:\Source\Project1\bin\Release\.NETFramework' does not exist for 'TheProject:TheBranch:TheProject:TheBranch:GUID' (base directory = C:\Source\Project1)
At the moment I'm working around the problem by deleting those files before invoking the runner with the 'end' verb, but would like to know if there is a better way or if this is a known bug.
Can anyone tell me if SonarQube should be able to handle these files, or if there is a configuration I should tweak to avoid the problem?
This isn't a known issue - thanks for reporting it. I've created SONARMSBRU-199 to track it.
Normally XXXAssemblyInfo.cs files are generated under the %TEMP% directory so they are automatically excluded from the analysis as they are not under the project folder. However, it's a valid file name so it should be possible to analyse it if it happens to be created under the project directory.
Related
I created a class library project and configured the properties section debug to start an exe (the.exe) located in the output directory of the build (as shown in the image).
It worked as long as we had a pre-build event copying the exe and all related files from one directory in the output directory of the build. Unfortunatly this is inconvinient and we do not have track which version of the exe is used.
So I created a versioned nuget package to place all the files in the output directory. I confirmed all the required files (I know of) are in the output directory. And since I created the nuget package manually with the CLI I can confirm they are exactly the same files.
But when I try to start the application from Visual Studio 2019 now I get the following error in the debug output:
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
The program '[16616] the.exe' has exited with code -2147450749 (0x80008083).
Actually both (the.exe and the class library) are .NET 5.
Comparing the changes of the two setups via Git changes does not hold any clues beside adding the nuget and removing the pre-build events.
So any clue what could be the difference/problem and how to get the executable running? May I missed something?
Well, better check twice when you are stating "I confirmed all the required files (I know of) are in the output directory."
The problem was that not all files made it into the output directory.
In my case only the the.exe and the.dll were placed into the output directory. Once I checked again and ensured that also the.runtimeconfig.json (which was missing) were added it was running again and the exception were gone. Though I am not sure if there is a better way than distributing the.runtimeconfig.json.
update visual studio using Visual Studio installer worked for me. This link! helped for me.
I am trying to publish my .NET 5 application, when publishing with Target runtime = Portable publish succeeds, when changing target runtime to win-x64 for example the publish fails.
Before failing i get this error in output which is probably related.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(131,5): Error : Invalid framework identifier ''.
I have noticed that the 'project.assets.json' is generated in 'obj\project.assets.json' dir but it looks like the build process actually expect it to be in 'obj\publish\win-x64\project.assets.json' and its not present there. Manually copying the file makes everything work but such approach would be very tedious.
Is there any project configuration I need to look into ?
Thanks.
Looks like the problem was caused by some dependent project libraries having AppendTargetFrameworkToOutputPath set to false.
I have a dotNet Core solution containing three projects - one common code, one "read-only" web service and one "admin" web service (which has all the POST, PUT and DELETE routes). The solution builds just fine locally and works. I want to build both projects and run both their publish operations to generate the output artifacts as part of the TFS Gated Check-In.
I have a build definition in TFS (2017) which includes a dotnet build task in which I specified the two project file paths and which has the following parameters...
/p:AssemblyVersion=$(Build.BuildNumber)
/p:Version=$(Build.BuildNumber) /p:DeployOnBuild=True
/p:PublishProfile=Dev.pubxml /p:AllowUntrustedCertificate=True
/p:Configuration=$(BuildConfiguration)
When the build runs it has no problem with the first project which builds just fine and correctly publishes, but when it then attempts to build the second project it comes up with the error...
Copyright (C) Microsoft Corporation. All rights reserved.
Restoring packages for e:\ci\builds\173\s\JMO.WebAPI\develop\JMOAdmin.WebAPI\JMOAdmin.WebAPI.csproj...
Restore completed in 23.62 ms for e:\ci\builds\173\s\JMO.WebAPI\develop\JMO.DAL\JMO.DAL.csproj.
Restore completed in 78.55 ms for e:\ci\builds\173\s\JMO.WebAPI\develop\JMO.WebAPI\JMO.WebAPI.csproj.
Restore completed in 34.6 ms for e:\ci\builds\173\s\JMO.WebAPI\develop\JMO.WebAPI\JMO.WebAPI.csproj.
Generating MSBuild file e:\ci\builds\173\s\JMO.WebAPI\develop\JMOAdmin.WebAPI\obj\JMOAdmin.WebAPI.csproj.nuget.g.props.
Restore completed in 1.3 sec for e:\ci\builds\173\s\JMO.WebAPI\develop\JMOAdmin.WebAPI\JMOAdmin.WebAPI.csproj.
JMO.DAL -> e:\ci\builds\173\s\JMO.WebAPI\develop\JMO.DAL\bin\dev\netcoreapp2.1\JMO.DAL.dll
CSC : error CS0006: Metadata file 'e:\ci\builds\173\s\JMO.WebAPI\develop\JMO.WebAPI\publish\System.EnterpriseServices.Wrapper.dll' could not be found [e:\ci\builds\173\s\JMO.WebAPI\develop\JMO.WebAPI\JMO.WebAPI.csproj]
Build FAILED.
CSC : error CS0006: Metadata file 'e:\ci\builds\173\s\JMO.WebAPI\develop\JMO.WebAPI\publish\System.EnterpriseServices.Wrapper.dll' could not be found [e:\ci\builds\173\s\JMO.WebAPI\develop\JMO.WebAPI\JMO.WebAPI.csproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:03.71
Error: C:\Program Files\dotnet\dotnet.exe failed with return code: 1
Dotnet command failed with non-zero exit code on the following projects : e:\ci\builds\173\s\JMO.WebAPI\develop\JMOAdmin.WebAPI\JMOAdmin.WebAPI.csproj
Here's the rub though, if I swap the order of the projects in the task it is still the second project that fails to build. What is more, if I add a second dotnet build task so there is one for each project it still does the same - the second build fails with the same error, irrespective of which actual project builds first. The same applies if I use a wildcard for the project file names.
The other thing to note is that the file specified in the error (System.EnterpriseServices.Wrapper.dll) is not to be found in either build's output path anyway, whether the build succeeds or not!
The only way I have found so far to get a successful build of both projects is to use the MultiConfiguration option with a Pass1,Pass2 value and enable/disable the build tasks so that it takes two entire passes at the process, once for the "read-only" WS and one for the admin WS. I'm guessing that something is getting stuck in memory during the first project build process and it's tripping up the second but I can't prove it so far.
My problem with this solution is that this only works on the develop branch, on the release branch I need to use the multi-configuration option for the intended purpose - the various target environments (test, uat, prod).
Short of installing a TFS extension to chain builds (not ideal but viable), can anyone suggest why I'm getting this behaviour and, more importantly, suggest a better solution.
Cheers.
Very common problem for many users, that SonarQube Code Analysis fails with an error:
[10:06:05]No ProjectInfo.xml files were found. Possible causes:
[10:06:05]1. The project has not been built - the end step was called right
after the begin step, without a build step in between
[10:06:05]2. An unsupported version of MSBuild has been used to build the
project. Currently MSBuild 12.0 upwards are supported
[10:06:05]3. The build step has been launched from a different working folder
[10:06:05]Post-processing failed. Exit code: 1
[10:06:05]Process exited with code 1
A lot of references say that fix is to use full path for MSBuild.exe, but yes, I use full path, but also I use MSBuild 15.0 version with newest C# version, older MSBuild just fails for new C# features in code.
However I can't get rid of this error and I have no idea what can be done about it, so maybe any of you guys have already met this problem and could help me?
EDITED
I am pretty sure that none of these steps should be the reason for the fail, the second one only the closest one, because my build steps are
Team City build steps look like the following.
Step XX:
cd %projectDirectory%
"C:\sonarqube-5.3\bin\MSBuild.SonarQube.Runner\MSBuild.SonarQube.Runner.exe" begin ... params
"C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\msbuild.exe" "MyProject.sln" /t:Clean;Rebuild
Step XY:
...
Step XZ: (the last)
cd %projectDirectory%
"C:\sonarqube-5.3\bin\MSBuild.SonarQube.Runner\MSBuild.SonarQube.Runner.exe" end
For me it looks very simple and easy to understand, but still I got that error and I have no idea why, the error is thrown in the last step (XZ).
You need to upgrade to a newer version of the Scanner for MSBuild. I'd suggest upgrading to the newest available version (v4.2 at the time of writing).
The scanner copies a targets file under the following location for each supported version of MBuild: %localappdata%\Microsoft\MSBuild[MSBuild version]\Microsoft.Common.targets\ImportBefore.
From the look of the log output you are using an version of the Scanner for MSBuild that pre-dates the release of MSBuild 15, so the file won't be copied to the MSBuild15-specific location. This will lead to the "no ProjectInfo.xml files were found" state.
It would be better if the warning message in the scanner log explicitly listed the range of MSBuild versions that were supported e.g. "This version of the Scanner supports MSBuild v12.0 to v14.0". I've created issue #502 to track this.
It was a long WTF moment and I could not find any information on the issue, so I decided I put it here.
Setup: Windows 7 x86_64, sonarqube-4.3, sonar-runner-2.4, jre 1.7.0_55-b14
I followed quick start guide to configure Sonar.
I copied sonar-project.properties from a sample to my solution, put it in the directory with .sln, and made necessary adjustments:
sonar.projectKey=org.whatever.project
sonar.projectName=Project
sonar.projectVersion=2.0
sonar.sourceEncoding=UTF-8
sonar.sources=.
sonar.visualstudio.enable=true
Problem: Analysis ran without any exceptions but only C# files were analyzed.
Long story short, following line in config was causing the issue:
sonar.sources=.
After moving sonar-project.properties one level up and changing it accordingly, the problem was resolved.
sonar.sources=src
I think it actually relates to the usage of the Visual Studio Bootstrapper. Can you try the same without it?
Here is what happens: The Visual Studio bootstrapper reads all the <Compile> tags from the *.csproj files to determine which files must be imported. Javascript files are not referenced by <Compile> (as they do not need to be compiled), and will therefore not be imported in SonarQube.
See this related Jira ticket: https://jira.codehaus.org/browse/SONARVS-27