I use the dotnet pack command in the yml file which packs the code into a NuGet package.
When the pack command runs in the pipeline,it says:
Successfully created a package 'E:\agentname....\45\a\Ayush.search.0.0.4.nupkg'
and when the push command works it says File does not exist
E:\agentname....\45\a/Ayush.search.0.0.4.nupkg.
The problem can be solved to run by changing the slash in the script- dotnet nuget push $(BUILD.STAGINGDIRECTORY)\ but for cloud builds forward slash is needed.
I use the dotnet pack command in the yml file which packs the code into a NuGet package.
-script: |
dotnet pack Ayush.search/Ayush.search/Ayush.search.csproj --version-suffix --configuration......
I have also used the dotnet nuget push command
-script: |
dotnet nuget push $(BUILD.STAGINGDIRECTORY)/Ayush.Search.*.nupkg --source " " --api-key ...
When the pack command runs in the pipeline,it says:
Successfully created a package 'E:\agentname....\45\a\Ayush.search.0.0.4.nupkg'
and when the push command works it says File does not exist
E:\agentname....\45\a/Ayush.search.0.0.4.nupkg.
The problem can be solved to run by changing the slash dotnet nuget push $(BUILD.STAGINGDIRECTORY)\ but for cloud builds forward slash is needed.
What can be done so the forward slash remains and the error gets solved?
I suppose that you could use the dotnet task instead of script command to do the operation.
pool:
vmImage: ubuntu-latest
steps:
- task: DotNetCoreCLI#2
inputs:
command: 'pack'
packagesToPack: '**/*.csproj'
versioningScheme: 'off'
- task: DotNetCoreCLI#2
inputs:
command: 'push'
packagesToPush: '$(Build.ArtifactStagingDirectory)/*.nupkg'
nuGetFeedType: 'internal'
publishVstsFeed: ''
Related
In our .NET Web API project, we tried to build API project in Azure DevOps and publish the artifact to a folder with the pipeline task below:
- task: DotNetCoreCLI#2
displayName: Publish web API artifact
inputs:
command: publish
publishWebProjects: false
arguments: '$(Build.SourcesDirectory)\XYZ.Research.API\XYZ.Research.API.csproj --configuration $(BuildConfiguration) --output testpath'
zipAfterPublish: true
modifyOutputPath: true
But I am not sure which folder the artifact is kept. Below is the log from this step:
2020-07-31T12:04:23.6282186Z ##[section]Starting: Publish web API artifact
2020-07-31T12:04:23.6590490Z ==============================================================================
2020-07-31T12:04:23.6591051Z Task : .NET Core
2020-07-31T12:04:23.6591393Z Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command
2020-07-31T12:04:23.6591740Z Version : 2.172.2
2020-07-31T12:04:23.6591974Z Author : Microsoft Corporation
2020-07-31T12:04:23.6592357Z Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
2020-07-31T12:04:23.6592942Z ==============================================================================
2020-07-31T12:04:25.5581194Z [command]C:\windows\system32\chcp.com 65001
2020-07-31T12:04:25.5581889Z Active code page: 65001
2020-07-31T12:04:25.5583746Z Info: .NET Core SDK/runtime 2.2 and 3.0 are now End of Life(EOL) and have been removed from all hosted agents. If you're using these SDK/runtimes on hosted agents, kindly upgrade to newer versions which are not EOL, or else use UseDotNet task to install the required version.
2020-07-31T12:04:25.5588792Z [command]C:\hostedtoolcache\windows\dotnet\dotnet.exe publish d:\a\1\s\XYZ.Research.API\XYZ.Research.API.csproj --configuration Release --output testpath
.....
some warning message ignored
.....
2020-07-31T12:04:38.0843543Z XYZ.Research.API -> d:\a\1\s\XYZ.Research.API\bin\Release\netcoreapp3.0\XYZ.Research.API.dll
2020-07-31T12:04:38.9127845Z XYZ.Research.API -> d:\a\1\s\testpath\
2020-07-31T12:04:46.0295716Z Info: Azure Pipelines hosted agents have been updated to contain .Net Core 3.x (3.1) SDK/Runtime along with 2.1. Unless you have locked down a SDK version for your project(s), 3.x SDK might be picked up which might have breaking behavior as compared to previous versions.
2020-07-31T12:04:46.0296632Z Some commonly encountered changes are:
2020-07-31T12:04:46.0297619Z If you're using `Publish` command with -o or --Output argument, you will see that the output folder is now being created at root directory rather than Project File's directory. To learn about more such changes and troubleshoot, refer here: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting
2020-07-31T12:04:46.0442329Z ##[section]Finishing: Publish web API artifact
Because we will need the file location in next step (deployment), I tried
d:\a\1\s\testpath\XYZ.Reserch.API.zip
d:\a\1\s\testpath\XYZ.Reserch.API\XYZ.Reserch.API.zip
but none of these location has the artifact file.
Did anyone see this issue before? Any help would be appreciated.
------------------- update -------------------------------
As #Source Code suggested, I used task "PowerShell#2" and find that the artifact file are actually in "D:\a\1\s\testpath\testpath.zip". That means the 'testpath' sub-folder are created in $(Build.SourceDirectory) and the artifact file are also renamed to 'test.zip'.
I would recommend that you add a PowerShell/Bash/Cmd task after your DotNetCoreCLI#2 task and run a inline script with the 'ls' command that should list all the items to the results for you. This will allow you to see what is actually there after the task.
If on a Windows agent:
- task: PowerShell#2
displayName: List Files Post Publish
inputs:
targetType: inline
script: Get-ChildItem
If on Linux or Mac
- task: Bash#3
displayName: List Files Post Publish
inputs:
targetType: inline
script: ls
Additionally I noticed you're providing your csproj file via the arguments parameter. There is a parameter named projects which should be used for this. Also you may consider using the the artifacts staging directory as your output directory. The task would look like this:
- task: DotNetCoreCLI#2
displayName: Publish web API artifact
inputs:
command: publish
projects: '$(Build.SourcesDirectory)\XYZ.Research.API\XYZ.Research.API.csproj'
publishWebProjects: false
arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
zipAfterPublish: true
modifyOutputPath: true
One important thing to note is if you do change the output directory ensure that you change the working directory for the PowerShell or Bash tasks so you output the contents of the correct directory. It defaults to the $(Build.SourcesDirectory) so ensure that you change this if needed.
In Azure DevOps, I'd like to use the dotnet core CLI task to push a package with the --skip-duplicate option set. How do I do that?
I tried to set arguments: --skip-duplicate, but that's not getting reflected in the executed command.
I tried custom command with custom: nuget push, but that indicates nuget push isn't a valid custom command.
How do I make the DotNetCorCLI#2 task perform dotnet nuget push <pathspec> --skip-duplicate (with also the --source option set to an internal package source)
Try to use custom: nuget and put the push in argument. Check the following syntax:
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet nuget push'
inputs:
command: custom
custom: nuget
arguments: 'push *.nupkg -s https://pkgs.dev.azure.com/xxxx/_packaging/xxx/nuget/v3/index.json --skip-duplicate'
You should be able to use the nuget authenticate and the nuget push instead of the dotnet core CLI. It has a couple of more features
- task: NuGetAuthenticate#0
displayName: 'NuGet Authenticate'
- task: NuGetCommand#2
displayName: 'NuGet push'
inputs:
packagesToPush: '$(Build.ArtifactStagingDirectory)/**/*.nupkg'
command: push
feedsToUse: 'select'
publishVstsFeed: 'feedname'
allowPackageConflicts: true
I had the same issue. I managed to fix it this way:
- task: NuGetAuthenticate#0
- script: dotnet nuget push --api-key az --skip-duplicate --source https://pkgs.dev.azure.com/{organization}/{project?}/_packaging/{feed1}/nuget/v3/index.json *.nupkg
workingDirectory: $(Build.ArtifactStagingDirectory)
Of course, replace {organization} with your org name in azure.
{project?} is useless if your feed is organization scoped and
{feed1} is your nuget feed name.
The NuGetAuthenticate task will authenticate by default all feeds within azure.
To get authentication works outside azure feeds, take a look to the official docs
Update
If nuget push randomly fails with 401, an accepted workaround is to add these variables to your yaml, as suggested here
variables:
NUGET_PLUGIN_REQUEST_TIMEOUT_IN_SECONDS: '30'
NUGET_PLUGIN_HANDSHAKE_TIMEOUT_IN_SECONDS: '30'
I've an ASP.NET Core application I'm publishing on a dedicated server via Azure DevOps build/release pipelines.
I'm managing the application version number with the GitVersion task (gittools.gitversion.gitversion-task.GitVersion#4) in the YAML build.
The build step is something like:
- task: DotNetCoreCLI#2
displayName: 'dotnet build'
inputs:
command: custom
custom: build
workingDirectory: src/MyAppProjectFolder
arguments: '-p:Version=$(GitVersion.FullSemVer)'
And is correctly generating the .exe with the given FullSemVer (I'm inspecting the Azure agent work folder)
Then I've the publish step:
- task: DotNetCoreCLI#2
displayName: 'dotnet publish'
inputs:
command: publish
publishWebProjects: false
arguments: '--output $(build.artifactstagingdirectory) --no-restore --no-build'
workingDirectory: src/MyAppProjectFolder
For some reason the same .exe i found in the C:\agent_work\1\a\a.zip created by the publish DOESN'T have the correct version number, but the generic 1.0.0.
If I "emulate" the pipelines manually on the same server (with dotnet build and dotnet publish manually via powershell, same parameters) everything works as expected.
What's going on? Is there a way to ensure the application to keep the $(GitVersion.FullSemVer) version?
Note: I had to add
- task: UseDotNet#2
displayName: 'Use .Net Core sdk 2.1.x'
inputs:
packageType: sdk
version: 2.1.x
installationPath: $(Agent.ToolsDirectory)/dotnet
includePreviewVersions: true
in front of each NET Core task, as explained here, after the agents have been updated to .NET Core 3.0 (before these builds worked well).
Try adding -p:Version=$(GitVersion.FullSemVer) to your arguments for the publish step.
I recently moved my sources to azure devOps to use cd/ci and all the other cool stuff.
Now i created my first build pipeline to build the android part of my Xamarin project. But I end up getting an error message, that a resource of a referenced project could not be found and i shall do a package restore and try again.
Now, since i have azure hosted build agents and not self hosted, i have no ways of setting the agent up properly before doing the build.
But i guess there should be some way to properly configure the build pipeline to do all the necessary stuff.
Its just that i have no clue what i should add to my yaml file in order to fix this stuff.
This is the error message i got:
##[error]C:\Program Files\dotnet\sdk\2.2.105\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(208,5): Error NETSDK1004: Assets file 'd:\a\1\s\*****\*****\*****\*****\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.
The problem is, that this file should be generated by compiling a referenced project and is not part of a nuget package.
Here is my build pipeline as far as i figured it out by myself.
# Xamarin.Android
# Build a Xamarin.Android project.
# Add steps that test, sign, and distribute an app, save build artifacts, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/xamarin
trigger:
- Share/main
pool:
vmImage: 'VS2017-Win2016'
variables:
buildConfiguration: 'Debug'
outputDirectory: '$(build.binariesDirectory)/$(buildConfiguration)'
steps:
- task: NuGetToolInstaller#1
inputs:
versionSpec: 5.1.0
- task: NuGetCommand#2
displayName: 'Restore NuGet Packages'
inputs:
command: restore
restoreSolution: '**/*.sln'
- task: XamarinAndroid#1
inputs:
projectFile: 'Mobile4/Droid/Mobile4.Droid.csproj'
outputDirectory: '$(outputDirectory)'
configuration: '$(buildConfiguration)'
- task: AndroidSigning#3
inputs:
apksign: false
zipalign: false
apkFiles: '$(outputDirectory)/*.apk'
- task: PublishBuildArtifacts#1
inputs:
pathtoPublish: '$(outputDirectory)'
The build always breaks on step XamarinAndroid
I hope you can help me.
The solution must be out there somewhere, i just cannot see it right now.
Thx in Advance.
Mav
[error]C:\Program Files\dotnet\sdk\2.2.105\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(208,5):
Error NETSDK1004: Assets file
'd:\a\1\s********************\obj\project.assets.json' not found.
Run a NuGet package restore to generate this file.
According to this error message, the project is .NetCore and its SDK used is 2.2.105. For the file "....\obj\project.assets.json", whether the project.assets.json exists is determined by package restore step. Now, it prompt this could not be found, it means the package restore does not restore this file successfully.
As I mentioned previously, it is a .NetCore project. So you should use dotnet restore instead of nuget restore. For .NetCore project, the obj folder restored by nuget restore does not contain project.assets.json in it.
So, to solve the issue you meet, you should replace the task Nuget restore as dotnet restore: dotnet.
- task: DotNetCoreCLI#2
displayName: 'dotnet restore'
inputs:
command: restore
projects: '**/*.csproj'
vstsFeed: 'e157d03d-******-fc06f9e13177'
I have a program MyProgram.csproj (which happens to be a .NET Core console app) and I am copying it's build (bin\netcoreapp2.2) into the release pipeline and trying to run it MyProgram.dll through Powershell as a task.
When I do so I get the error
2019-08-14T01:35:58.1153997Z An assembly specified in the application dependencies manifest (MyProgram.deps.json) was not found:
2019-08-14T01:35:58.1154837Z package: 'Autofac', version: '4.2.1'
2019-08-14T01:35:58.1155904Z path: 'lib/netstandard1.1/Autofac.dll'
The reference is
"Autofac/4.2.1": {
"dependencies": {
"System.ComponentModel": "4.0.1"
},
"runtime": {
"lib/netstandard1.1/Autofac.dll": {
"assemblyVersion": "4.2.1.0",
"fileVersion": "4.2.1.0"
}
}
}
Any way I can get more information about why this assembly cannot be found?
Can you try adding the following to my .csproj:
<PropertyGroup>
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
and try updating all the references on the project
The better way to get rid of dependency chaos is to deploy a self-contained publish, so that includes .NET Core libraries, the .NET Core runtime and referenced package dependencies.
Following this link, you can determine the runtime identifier (e.g. win-x64) and the configuration settings for release or debug builds.
dotnet publish .\MyProgram.csproj -c Release -r "win-x64" --self-contained -o .\publish
You can either use the dotnet extension in the build definition or add a powershell inline command to run the mention codes.
YAML Example
resources:
- repo: self
queue:
name: DefaultAgentPool
steps:
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
feedsToUse: config
nugetConfigPath: nuget.config
- powershell: |
# Write your powershell commands here.
Write-Host "Starting dotnet cli publish command ..."
dotnet publish --runtime "win-x64" -o $(Build.ArtifactStagingDirectory) -c Release --self-contained
workingDirectory: src/Project
displayName: 'dotnet publish'
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: win'
inputs:
ArtifactName: win-publish
This makes you sure that you're not going to get any dependency error in the specified runtime platform.