We have an ADO Build pipeline, which need download a nuget package from a remote feed.
Using a Windows agent, we can do something like
- task: NuGetCommand#2
displayName: Downloading nuget package
inputs:
command: custom
arguments: install "{{ parameters.packageName}}" d -source "${{ parameters.nugetFeed }}"
However, now we have switched to MarinerOS, which does not have mono installed, so nuget.exe is not working.
After searching around, DotNetCoreCLI#2 task is working in Linux OS, however in order to download a package, it needs a project file to be able to add the project reference and then restore the package.
- task: DotNetCoreCLI#2 // won't work as it cannot find any project files
displayName: Downloading nuget package
inputs:
command: 'custom'
arguments: package SomePackageName
vstsFeed: $(NugetFeed)
feedsToUse: 'select'
custom: 'add'
Since we do not have any project files nor solution files in our pipeline, how can we download a nuget package without Nuget.exe in ADO pipeline?
Related
I've got a build pipe for an Azure Function using .Net Core 3.1.x. All the steps until the publishing are doing fine. I can get the publish step working by using script, but not through the yaml task. What am I missing?
Script (works)
- script: dotnet publish --configuration Release .\af-process-mds-vehicle-output-to-deviation\af-process-mds-vehicle-output-to-deviation.csproj
Task (does not work)
- task: DotNetCoreCLI#2
displayName: 'Publish Project'
inputs:
command: 'publish'
configuration: 'Release'
projects: '.\af-process-mds-vehicle-output-to-deviation\af-process-mds-vehicle-output-to-deviation.csproj'
zipAfterPublish: true
It doesn't find the project.
Here's the error message.
2021-10-29T05:21:44.3024816Z ##[section]Starting: dotnet publish
2021-10-29T05:21:44.3150367Z ==============================================================================
2021-10-29T05:21:44.3150726Z Task : .NET Core
2021-10-29T05:21:44.3151190Z Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command
2021-10-29T05:21:44.3151475Z Version : 2.187.0
2021-10-29T05:21:44.3151733Z Author : Microsoft Corporation
2021-10-29T05:21:44.3152035Z Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
2021-10-29T05:21:44.3152373Z ==============================================================================
2021-10-29T05:21:44.7797987Z [command]C:\Windows\system32\chcp.com 65001
2021-10-29T05:21:44.7903026Z Active code page: 65001
2021-10-29T05:21:44.7927221Z 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.
2021-10-29T05:21:44.8938257Z ##[error]No web project was found in the repository. Web projects are identified by presence of either a web.config file, wwwroot folder in the directory, or by the usage of Microsoft.Net.Web.Sdk in your project file. You can set Publish web projects property to false (publishWebProjects: false in yml) if your project doesn't follow this convention or if you want to publish projects other than web projects.
2021-10-29T05:21:44.9001249Z Info: Azure Pipelines hosted agents have been updated and now contain .Net 5.x SDK/Runtime along with the older .Net Core version which are currently lts. Unless you have locked down a SDK version for your project(s), 5.x SDK might be picked up which might have breaking behavior as compared to previous versions. You can learn more about the breaking changes here: https://learn.microsoft.com/en-us/dotnet/core/tools/ and https://learn.microsoft.com/en-us/dotnet/core/compatibility/ . 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
2021-10-29T05:21:44.9003648Z ##[error]Project file(s) matching the specified pattern were not found.
2021-10-29T05:21:44.9182124Z ##[section]Finishing: dotnet publish
After the tips from the answer I got the pipe working. Here's the full working pipe. (Still don't know why it didn't work earlier.)
Working pipe:
name : af-vehicle-sync-to-deviation
## if there is a change is the deviation folder for the main branch. Then trigger.
trigger:
branches:
include:
- main
paths:
include:
- af-process-mds-vehicle-output-to-deviation/*
pool:
vmImage: 'windows-latest'
variables:
buildConfiguration: 'Release'
SolutionPath: '**\*.sln'
stages:
- stage: Build
displayName: Build solution
jobs:
- job: Build
displayName: Build and publish solution
steps:
- checkout: self
- task: NuGetToolInstaller#1
- task: NuGetCommand#2
inputs:
restoreSolution: $(SolutionPath)
- task: UseDotNet#2
inputs:
packageType: 'sdk'
version: '3.1.x'
displayName: 'Use .NET Core SDK 3.1.x'
- task: DotNetCoreCLI#2
inputs:
command: 'build'
configuration: $(buildConfiguration)
projects: '$(SolutionPath)'
displayName: 'Build solution'
- task: DotNetCoreCLI#2
displayName: 'Publish Project'
inputs:
command: 'publish'
configuration: 'Release'
projects: '**\*.csproj'
publishWebProjects: false
zipAfterPublish: true
arguments: '--output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
- task: PublishBuildArtifacts#1
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop'
publishLocation: 'Container'
You could use '**/*.csproj' but honestly, I would do something like this answer and add a script to list out all the files and folders recursively before this step that fails.
Assuming that you have a restore or build step before this publish you could add it after those, or just as the first step after your checkout one.
You can also inspect the logs of earlier steps to see the file path/s., instructions on doing this are available here.
Using $(System.DefaultWorkingDirectory) as your root is also recommended, rather than .\, so you would have '$(System.DefaultWorkingDirectory)\af-process-mds-vehicle-output-to-deviation...'.
Edit
If you look at the logs for your build step you will see entries like /home/vsts/work/1/s/XXX.YYY.ZZZ/XXX.YYY.ZZZ.csproj that refer to the different projects inside your solution. By default most commands will be run in $(System.DefaultWorkingDirectory) which would equate to /home/vsts/work/1/s/ in this instance, you can think of it as the root of your repository - there is more information on this structure here.
The error you were encountering is actually about the lack of a web project, rather than a path issue though, for the build step it is best practice to use the --output <output-directory-here> flag to output the compile files into a specific folder, that way you can easily publish that folder.
I am setting up an Azure Build pipeline to automatically build when a NuGet package get's published. In that build definition - I want to install the latest version of the package.
According to this answer, I need to restore packages first to authenticate against Dev Ops feeds.
I have set-up a build.yml file to include these tasks:
- task: DotNetCoreCLI#2
displayName: 'Restore Packages'
inputs:
command: restore
projects: web/*.csproj
vstsFeed: organizational-packages
- task: DotNetCoreCLI#2
displayName: Install Custom Internal Package Package
inputs:
command: 'custom'
custom: 'add'
arguments: 'package Custom.Internal.Package --prerelease'
projects: 'Web/*.csproj'
feedsToUse: 'select'
feedRestore: 'organizational-packages'
The NuGet feed is hosted in Azure Dev ops and has organizational scope.
When I go to run the build - the Azure Package feed is not included in the search for the package:
info : Adding PackageReference for package 'Custom.Internal.Package' into project
'/home/vsts/work/1/s/Project.Web/Web.csproj'.
info : GET https://api.nuget.org/v3/registration5-gz-semver2/custom.internal.package/index.json
info : NotFound https://api.nuget.org/v3/registration5-gz-semver2/cbh.surescripts.business/index.json 202ms
error: There are no versions available for the package 'Custom.Internal.Package'.
The package is located at https://myorg.pkgs.visualstudio.com/_packaging/organizational-packages/nuget/v3/index.json
I even tried accomplishing this with just the command line tasks:
- task: NuGetAuthenticate#0
displayName: Authenticate NuGet Feed
- task: CmdLine#2
displayName: Add Organizational Package Source
inputs:
script: 'dotnet nuget add source https://myorg.pkgs.visualstudio.com/_packaging/organizational-packages/nuget/v3/index.json -n credible'
- task: CmdLine#2
displayName: Install Custom Internal Package
inputs:
script: 'dotnet add package Custom.Internal.Package--prerelease'
workingDirectory: '$(Build.SourcesDirectory)/Web'
In the later case the package source is added - but I am getting an unauthorized error:
info : Adding PackageReference for package 'Custom.Internal.Package' into project '/home/vsts/work/1/s/Project.Web/Web.csproj'.
info : GET https://api.nuget.org/v3/registration5-gz-semver2/custom.internal.package/index.json
info : NotFound https://api.nuget.org/v3/registration5-gz-semver2/custom.internal.package/index.json 64ms
error: Unable to load the service index for source https://myorg.pkgs.visualstudio.com/_packaging/organziational-packages/nuget/v3/index.json.
error: Response status code does not indicate success: 401 (Unauthorized).
There is no feedsToUse in custom command in DotNetCoreCLI task, you could remove it, and try to add -v|--version <VERSION> to version the package:
- task: DotNetCoreCLI#2
displayName: 'dotnet custom'
inputs:
command: custom
projects: 'Web/*.csproj'
custom: add
arguments: 'package Custom.Internal.Package --prerelease -v 1.0.0'
I am trying to build a repository in Azure Pipelines. It builds OK in Visual Studio, but when using Azure Pipelines (with an agent running on a build machine), it fails with the following error:
The nuget command failed with exit code(1) and error
Project MyProject is not compatible with netcoreapp2.2 (.NETCoreApp,Version=v2.2).
Project MyProject supports: netstandard2.0 (.NETStandard,Version=v2.0)
How can I fix this?
And here is the yaml build script:
pool:
name: MyBuildServer
demands:
- msbuild
- visualstudio
steps:
- task: NuGetCommand#2
displayName: 'NuGet restore'
- task: VSBuild#1
displayName: 'Build solution **\*.sln'
- task: VSTest#2
displayName: 'Run tests'
inputs:
testSelector: 'testAssemblies'
testAssemblyVer2: |
**\*test*.dll
!**\*TestAdapter.dll
!**\obj\**
searchFolder: '$(System.DefaultWorkingDirectory)'
NuGet Restore task fails (not compatible with netcoreapp2.2), but it works in Visual Studio
It seems that the version of nuget used on the Azure pipeline is not the latest version, which may cause the incompatibility issues.
To resolve this issue, you can try to add a NuGet Tool Installer task point it to a Version of NuGet.exe to install, which you simply specify the version number of the desired NuGet.exe you want to execute in the build.
Once this have been properly configured, the builds all succeeded using the latest incarnation of .net core.
Besides, if above not resolve your question, you can try to use the dotnet restore task instead of nuget restore task.
Hope this helps.
Trying to use azure yml for build pipleline to publish symbols to allow nuget pkg to be debuggable usin azure devops. I see PDB files are donwloaded to the symbols cache folder but stepping thru is asking for source file location in visual studio, even when i have indexed the source code during publish symbol.
I have tried to enable different options in visual studio debugging but nothing seems to help
Here is my yml
# ASP.NET Core
# Build and test ASP.NET Core projects targeting .NET Core.
# Add steps that run tests, create a NuGet package, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/dotnet-core
name: $(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r) # need this for byBuildNumber verisonScheme nuget pack
# the build will trigger on any changes to the master branch
trigger:
- master
# the build will run on a Microsoft hosted agent, using the lastest Windows VM Image
pool:
vmImage: 'windows-latest'
# these variables are available throughout the build file
# just the build configuration is defined, in this case we are building Release packages
variables:
buildConfiguration: 'Release'
#The build has 3 seperate tasks run under 1 step
steps:
# The first task is the dotnet command build, pointing to our csproj file
- task: DotNetCoreCLI#2
displayName: 'dotnet build'
inputs:
command: 'build'
arguments: '--configuration $(buildConfiguration)'
projects: 'src/Common.Core/Common.Core.csproj'
- task: PublishSymbols#2
inputs:
symbolsFolder: '$(Build.SourcesDirectory)'
searchPattern: '**/bin/**/*.pdb'
indexSources: true
publishSymbols: true
symbolServerType: 'teamServices'
treatNotIndexedAsWarning: true
symbolsProduct: '$(Build.DefinitionName)'
symbolsVersion: '$(Build.BuildNumber)'
symbolsArtifactName: '$(name).Symbols_$(BuildConfiguration)'
# The second task is dotnet pack command again pointing to the csproj file
# The nobuild means the project will not be compiled before running pack, because its already built in above step
- task: DotNetCoreCLI#2
displayName: "dotnet pack"
inputs:
command: 'pack'
arguments: '--configuration $(buildConfiguration)'
packagesToPack: 'src/Common.Core/Common.Core.csproj'
nobuild: true
includeSymbols: true
versioningScheme: 'byBuildNumber'
# The last task is a nuget command, nuget push
# This will push any .nupkg files to the 'Nuget' artifact feed
# allowPackageConflicts allows us to build the same version and not throw an error when trying to push
# instead it just ingores the latest package unless the version changes
- task: NuGetCommand#2
displayName: 'nuget push'
inputs:
command: 'push'
feedsToUse: 'select'
packagesToPush: '$(Build.ArtifactStagingDirectory)/**/*.nupkg;!$(Build.ArtifactStagingDirectory)/**/*.symbols.nupkg'
nuGetFeedType: 'internal'
publishVstsFeed: 'myNuget'
allowPackageConflicts: true
I would expect that when i am debugging nuget packages with symbols enabled with idnexed soruce code, it automatically downloads the pdf file and the source code.
Visual Studio Settings for debugger
I see PDB files are donwloaded to the symbols cache folder but
stepping thru is asking for source file location in visual studio,
even when i have indexed the source code during publish symbol.
You should let the debugger know where to find your source files. First, please rename your xx.nupkg to xx.zip and check if it contains necessary source files.
After that you can right-click Solution in Solution Explorer=>Properties=>Debug Source Files,click the New Line option to add the path of your nuget source files to the debug source files setting.
I would expect that when i am debugging nuget packages with symbols
enabled with idnexed soruce code, it automatically downloads the pdf
file and the source code.
Maybe you can get some help from this issue. You can try setting the build action of the source files as C# compiler when you create the nuget package for .net core.
I'm new to Azure DevOps; however, what I'm doing seems like it should be straightforward: I simply want to compile a project and publish to NuGet.org. I'm hitting that many barriers to doing it that I feel that I'm probably mis-using the tool.
I have a build which looks like this:
trigger:
- master
pool:
vmImage: 'windows-2019'
variables:
buildConfiguration: 'Release'
steps:
- script: dotnet build --configuration $(buildConfiguration) /property:Version=$(Build.BuildNumber)
displayName: 'dotnet build $(buildConfiguration)'
- task: PublishBuildArtifacts#1
inputs:
pathtoPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: 'drop'
This successfully builds. However, I do get the following warning:
##[warning]Directory 'd:\a\1\a' is empty. Nothing will be added to build artifact 'drop'.
When I try to deploy, I'm getting errors - the latest of which is:
No files matched the search pattern.
In dotnet pack, here's the release step for pack:
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet pack'
inputs:
command: pack
packagesToPack: '$(System.DefaultWorkingDirectory)/name.project'
This is what's currently failing, but the next step is intended to publish to NuGet (for completeness - and incase there's an easier way to do all this):
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet pack'
inputs:
command: pack
packagesToPack: '$(System.DefaultWorkingDirectory)/name.project'
The release has an artifact, which I've set up as the output from the build (I think); however, I get the error from this:
No version is available for name.project or the latest version has
no artifacts to publish. Please check the source pipeline.
My understanding of how this should work in general is that the Build should hold the steps involved in producing the binaries, etc, whereas the Release should be any steps involved in deploying the built. So, I should be able to take a 'Build' and 'Release' it several times to multiple locations. I feel like this understanding is not in-keeping with the errors that I'm seeing.
Is my understanding correct?
What could I be doing wrong here and, more importantly, what are the methods of diagnosing issues with this?
Trying to publish a build to Nuget.org
For the first error, that because you are mising the Copy Files task before using the Publish Build Artifacts task.
Check the Publish Build Artifacts task, you can view this task is used to publish build artifacts to Azure Pipelines, TFS, or a file share.
But after build the project/solution, the output are stored on the build agent, rather than the artifacts. So we need to add a copy task before PublishBuildArtifacts to copy the files from output to the artifacts:
steps:
- task: CopyFiles#2
displayName: 'Copy Files to: $(build.artifactstagingdirectory)'
inputs:
SourceFolder: '$(system.defaultworkingdirectory)'
TargetFolder: '$(build.artifactstagingdirectory)'
enabled: false
For the second error, you should specify the project in the repos instead of System.DefaultWorkingDirectory, where is use to build the project, change the Path to csproj in the repos:
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet pack'
inputs:
command: pack
packagesToPack: NetCoreDemo/NetCoreDemo/NetCoreDemo.csproj
Hope this helps.
You man need to provide the --output argument for dotnet build. Add the following
--output $(Build.ArtifactStagingDirectory)
so the command should look something like this.
dotnet build --configuration $(buildConfiguration) /property:Version=$(Build.BuildNumber) --output $(Build.ArtifactStagingDirectory)
this will put the output into the Artifact Staging Directory (d:\a\1\a)
which will include the *.nupkg file.
I am assuming you are using the new CSProj format and you are supplying the properties for the NuGet package and have the <GeneratePackageOnBuild>true</GeneratePackageOnBuild> property already set. If so the *.nupkg file should be in the output directory that you define in the dotnet build command. Then you don't need to use dotnet pack. In the release definition you just need to use the NuGet task and use push command to push the package to your NuGet Feed.
Use this blog post as reference. It does not have the full details since its focusing only on few aspects of the entire process. but it should be helpful to get the build aspect correct.