Trying to create a build configuration in Azure DevOps, using the new YAML build feature, however I can't seem to get NuGet restore to work when referring to a NuGet.config file (places in the root of my projectfolder)
In my YAML build file I have:
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: '$(Parameters.solution)'
feedsToUse: config
nugetConfigPath: 'NuGet.config'
In my log I get the following:
2018-09-25T17:25:07.4624712Z ##[section]Starting: NuGet restore
2018-09-25T17:25:07.4631787Z ==============================================================================
2018-09-25T17:25:07.4631904Z Task : NuGet
2018-09-25T17:25:07.4632707Z Description : Restore, pack, or push NuGet packages, or run a NuGet command. Supports NuGet.org and authenticated feeds like Package Management and MyGet. Uses NuGet.exe and works with .NET Framework apps. For .NET Core and .NET Standard apps, use the .NET Core task.
2018-09-25T17:25:07.4632875Z Version : 2.0.41
2018-09-25T17:25:07.4632964Z Author : Microsoft Corporation
2018-09-25T17:25:07.4633086Z Help : [More Information] (https://go.microsoft.com/fwlink/?LinkID=613747)
2018-09-25T17:25:07.4633196Z ==============================================================================
2018-09-25T17:25:08.2066658Z SYSTEMVSSCONNECTION exists true
2018-09-25T17:25:08.2581545Z SYSTEMVSSCONNECTION exists true
2018-09-25T17:25:08.3645811Z [command]C:\Windows\system32\chcp.com 65001
2018-09-25T17:25:08.3743733Z Active code page: 65001
2018-09-25T17:25:08.4044581Z Detected NuGet version 4.7.0.5148 / 4.7.0+9245481f357ae542f92e6bc5e504fc898cfe5fc0
2018-09-25T17:25:08.4061452Z SYSTEMVSSCONNECTION exists true
2018-09-25T17:25:08.4082708Z Saving NuGet.config to a temporary config file.
2018-09-25T17:25:08.4321725Z ##[section]Finishing: NuGet restore
I've tried using
nugetConfigPath: '$(Build.SourcesDirectory)\\NuGet.config'
instead, with the same result
Any ideas on how to get NuGet restore to work with a NuGet.config file?
I've figured it out, the NuGet task needs to be changed to:
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: '**\*.sln'
feedsToUse: config
nugetConfigPath: 'NuGet.config'
(The only thing which needed changing is restoreSolution.)
I also ran into this. I added the nuget.config to the solution(like any other class or interface) and it needed to be added where the .sln file was located.
e.g. If you didn't click the "Place solution and project in same directory" check box on project creation. Move the nuget.config one level up in your project.
Related
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?
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 can't solve an error from Nuget Restore in pipeline of Azure DevOps.
Starting: NuGet restore
==============================================================================
Task : NuGet
Description : Restore, pack, or push NuGet packages, or run a NuGet command. Supports NuGet.org and
authenticated feeds like Azure Artifacts and MyGet. Uses NuGet.exe and works with .NET Framework apps. For .NET Core and .NET Standard apps, use the .NET Core task.
Version : 2.161.0
Author : Microsoft Corporation
Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/package/nuget
==============================================================================
##[error]No neutral-language version resource found in the file
Finishing: NuGet restore
this is my NUGET Restore step in YAML:
steps:
- task: NuGetToolInstaller#1
displayName: 'Use NuGet 3.5.0'
inputs:
versionSpec: 3.5.0
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: 'Projects/Wpf Helper.sln'
vstsFeed: '9d280068-ebce-4e32-9320-8e07068cc0e0'
I've read this topic and changed nuget version from 3.5.0 to 5.3.1, none of these version helps, same error : No neutral-language version resource found in the file.
How can I solve this problem?
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 trying to create a Release Pipeline in Azure DevOps that will publish a package to Nuget.org. The build pipeline works just fine and creates the package as the build artifact. I can publish to a feed hosted in Azure Artifacts, I just cannot publish to Nuget.org. I believe the issue is with the Service Connection. .
I've tried using the ApiKey but that throws an error
DotNet Core does not support encrypted API Key' error
Here is the release step that is attempting to push the package.
I've also tried https://api.nuget.org/v3/index.json for the Feed URL but that doesn't seem to make a difference.
Log output.
2018-10-21T23:27:36.3177322Z ##[section]Starting: Nuget Push
2018-10-21T23:27:36.3183449Z ==============================================================================
2018-10-21T23:27:36.3183547Z Task : .NET Core
2018-10-21T23:27:36.3183635Z Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command. For package commands, supports NuGet.org and authenticated feeds like Package Management and MyGet.
2018-10-21T23:27:36.3183729Z Version : 2.141.0
2018-10-21T23:27:36.3183791Z Author : Microsoft Corporation
2018-10-21T23:27:36.3183871Z Help : More Information
2018-10-21T23:27:36.3183936Z ==============================================================================
2018-10-21T23:27:37.1663123Z [command]C:\Windows\system32\chcp.com 65001
2018-10-21T23:27:37.1762529Z Active code page: 65001
2018-10-21T23:27:37.1808736Z SYSTEMVSSCONNECTION exists true
2018-10-21T23:27:37.3473599Z SYSTEMVSSCONNECTION exists true
2018-10-21T23:27:37.4707171Z SYSTEMVSSCONNECTION exists true
2018-10-21T23:27:37.4739974Z e3e8a3af-5c6c-44e9-820c-c62af0972256 exists true
2018-10-21T23:27:37.4807474Z Saving NuGet.config to a temporary config file.
2018-10-21T23:27:37.4833034Z Saving NuGet.config to a temporary config file.
2018-10-21T23:27:37.4919745Z Using authentication information for the following URI: https://www.nuget.org/api/v2/package
2018-10-21T23:27:37.4988034Z [command]C:\hostedtoolcache\windows\dncs\2.1.105\x64\dotnet.exe nuget push "{package}" --source https://www.nuget.org/api/v2/package --api-key RequiredApiKey
2018-10-21T23:27:38.3984300Z info : Pushing TranslatorConsole.1.0.0.6.nupkg to 'https://www.nuget.org/api/v2/package'...
2018-10-21T23:27:38.4171650Z info : PUT https://www.nuget.org/api/v2/package/
2018-10-21T23:27:38.8798808Z info : Forbidden https://www.nuget.org/api/v2/package/ 462ms
2018-10-21T23:27:38.9562536Z error: Response status code does not indicate success: 403 (The specified API key is invalid, has expired, or does not have permission to access the specified package.).
2018-10-21T23:27:40.2195255Z ##[error]Error: C:\hostedtoolcache\windows\dncs\2.1.105\x64\dotnet.exe failed with return code: 1
2018-10-21T23:27:40.2206711Z ##[error]Packages failed to publish
2018-10-21T23:27:40.2307763Z ##[section]Finishing: Nuget Push
There is an issue tracked in Github: DotNetCore currently does not support using an encrypted Api Key
Using an ApiKey is currently not supported in dotnet because the
required libraries for encrypting the key are not available, sorry for
the inconvenience. You should be able to use a service endpoint
configured with a username/password combination. If you can only use
an ApiKey, I would suggest using the nuget 2.* task to push.
So, you can try using the Nuget 2.* task to push the packages. (Add task --> Package --> Nuget)
Alternately you can try pushing package to NuGet server through Command Line task by calling dotnet nuget push command to deal with this issue. Reference this thread: error while trying to push nuget package from VSTS
I was dealing with the same problem - publish a nuget to the NuGet.org feed from Azure DevOps. Despite the fact that this answer is still valid, there is an easy way how to do it and the answer didn't help me much.
Solution
Step 1
Generate ApiKey in NuGet.org administration.
Step 2
Add ApiKey as a secret variable to your pipeline.
The final product should look like this:
Step 3
Update your pipeline YAML with a PowerShell task with
- task: PowerShell#2
inputs:
targetType: 'inline'
script: 'nuget push $(Build.ArtifactStagingDirectory)\*.nupkg -ApiKey $(myNuGetApiKey) -Source https://api.nuget.org/v3/index.json'
You don't have to change anything in this task. It will work with any standard way of NuGet packing provided by Azure DevOps.
Publish your updated yaml pipeline and you are good to go.
Whole pipeline
trigger:
- master
pool:
vmImage: 'windows-latest'
steps:
- task: NuGetToolInstaller#1
inputs:
versionSpec: '5.7.0'
checkLatest: true
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: '**/YourProjectNameOr*ForAll.csproj'
- task: NuGetCommand#2
inputs:
command: pack
packagesToPack: '**/YourProjectNameOr*ForAll.csproj'
- task: PowerShell#2
inputs:
targetType: 'inline'
script: 'nuget push $(Build.ArtifactStagingDirectory)\*.nupkg -ApiKey $(myNuGetApiKey) -Source https://api.nuget.org/v3/index.json'
- task: PowerShell#2
inputs:
targetType: 'inline'
script: 'nuget push $(Build.ArtifactStagingDirectory)\*.snupkg -ApiKey $(myNuGetApiKey) -Source https://api.nuget.org/v3/index.json'
Note: The second task is for publishing a symbol package. If your project doesn't support the source link, you can omit this task. This article from Karam Nandwani, the NuGet Program Manager, states that botch packages, *.nupkg and *.snupkg will by published automatically by one nuget command, but it's true. At least for now.