While running my pipeline, it fails at the publish phase with 2 errors.
##[error]Error: The process 'C:\Program Files\dotnet\dotnet.exe' failed with exit code 1
##[error]Dotnet command failed with non-zero exit code on the following projects : ...
The pipeline also lists all paths to files with duplicate names, even if the contents are different. The pipeline worked fine before with the duplicate names, but now throws and error and will not proceed. what is the correct fix for this?
I think my pipeline is using Dotnet6 even though the app is only 3.1, and this was added to fix it. I don't know if this is the correct fix, but it is working.
I added this to the csproj files that have duplicate file names.
<PropertyGroup>
<ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles>
</PropertyGroup>
This is where I found it.
https://learn.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#erroronduplicatepublishoutputfiles
This is a breaking change introduced in .NET 6
https://learn.microsoft.com/en-us/dotnet/core/compatibility/sdk/6.0/duplicate-files-in-output
You have multiple ways of fixing this:
Evaluate your resources in the project where "CopyToOutputFolder" is set to "Always" and remove if they are unnecessary. How MSBuild handles this is, it tries to copy these resources to output folder after the build is completed.
Target a specific SDK during the build by adding it in global.json
https://learn.microsoft.com/en-us/dotnet/core/versions/selection
You probably have "rollForward" option set to "latestFeature" that automatically uses the latest SDK, so you can remove that and target .NET 5 or earlier.
Related
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.
I upgrade to Visual Studio 2017 15.8.1 and am having issues creating an Azure function project. The project I am trying to create is through the template wizard, just a new V1 empty function project.
I receive the following error, which seems to be .net core related.
NETSDK1004 Assets file '\obj\project.assets.json' not
found. Run a NuGet package restore to generate this
file. FunctionApp1 C:\Program Files\dotnet\sdk\2.1.400\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets 198
Run a NuGet package restore to generate this file.
But my project file states:
<PropertyGroup>
<TargetFramework>net461</TargetFramework>
<AzureFunctionsVersion>v1</AzureFunctionsVersion>
</PropertyGroup>
Just to be clear, I do want a 4.6.1 project, not a core one.
I have looked at other answers to this issue but none resolve it. Package reinstall, dotnet restore etc. I get more errors if I select a different template (e.g. HTTP Trigger)
Any ideas?
I thought I had a solution to reboot, then open %temp% and delete all the temporary files in that folder. Then reboot again for good measure and it worked from a blank / empty project, but as soon as I try include this in another solution or move the project it fails.
Seems I have it working now and I'll leave this here in case anyone else has the same.
I did try many many things to resolve, but I believe the crux of my fix was to reboot, then open %temp% and delete all the temporary files in that folder. Then I rebooted again for good measure and it worked from a blank / empty project.
Well that wasted a chunk of my day. I had created a repo in git which had a space in the name. When cloned I ended up with an encoded view of the repo - i.e. a %20 for the space, which appeared in the folder path. Since this was just some demo work I had left it as is instead of tidying it up to a clean namespace.
Turns out if you have a %20 or some other encoded value in your path you will get the NETSDK1004 error. I hope this answer saves someone else some time!
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.
I've been trying to run code analysis of several .Net Core 1.1 projects, but have failed to get any results.
While using VS2015 and the project.json format I successfully sent the command:
../Sonar/tools/sonar-scanner-2.8/bin/sonar-scanner
and the sonar server shows each of the files in project(s) and test projects(s), but no analysis has actually been carried out:
Lines of code = 0
Vulnerabilities = 0
code smells = 0
Having migrated the projects to VS2017 and the csproj format, I can't even get the scan to run.
Running in the main project folder:
SonarQube.Scanner.MSBuild.exe begin /k:"Car.Enquiry-Presenter" /n:"Car.Enquiry-Presenter" /v:"1.0" (no prolems here)
msbuild Car.EnquiryPresenter.csproj
throws error: "error MSB4066: The attribute "Version" in element is unrecognized."
I can see here that the dotnet cli is not yet supported
https://jira.sonarsource.com/browse/SONARMSBRU-310
But this post suggests that it is possible:
https://www.sonarsource.com/resources/product-news/news.html#2017-04-13-sonarqube-scanner-for-msbuild-2-3-released
'support for .NET Core projects: SONARMSBRU-167'
But I've been unable to get this to work.
Can anyone help?
Yes is the answer (great, I get to answer my own question!).
I've just got it working using v15 of MSBuild, but I needed to fully qlaulify the path to the exe, otherwise it continued to use v14:
MSBuild.SonarQube.Runner.exe begin /key:"Car.Enquiry-Presenter" /name:"Car.Enquiry-Presenter" /version:"1.0"
"../../../../Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\msbuild.exe"
MSBuild.SonarQube.Runner.exe end
I also needed to add a 'ProjectGuid' node to my csproj file containing a guid (i just generated that with https://www.guidgen.com/)
NB: Overriding the toolset you use in the csproj file does not force it to use v15. ie: ... .
Hence the fully qualified path.
you need to ensure that the nuget packages are updated using a "dotnet restore" before calling msbuild.exe too.