I'm running self-hosted agent and NuGetToolInstaller was always throwing an error ERR:unable to get local issuer certificate.
I found a fix-hack here. Just to download needed nuget.exe version to the machine, add it to Environment Variables and remove NuGetToolInstaller at all. It fixed the issue, but today I understood that it's not really so.
Currently, I have nuget.exe version 5.6.0 so I thought self-hosted agent uses it but...
While running Initialize Job Azure downloads NuGetCommand
I found the location and can see that it downloads three different versions of nuget.exe
And it always uses 4.1.0 for any NuGetCommand.
How can I specify which version of NuGet to use without NuGetToolInstaller?
Or how to make Initialize Job not downloading any nuget.exe and just use that one available in the system?
For testing I deleted everything from the yaml and it looks like this:
trigger:
- master
pool:
name: somePool
jobs:
- job: someJob
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
From the pipeline log, it seems nuget task use v4.1 by default:
If you don't want to use NuGetToolInstaller task, one workaround is replacing the nuget.exe with the version you want to use in the {agent work folder}\_tool\NuGet\4.1.0\x64 folder.
Related
I'm configuring an ADO Build Pipeline, however, it's failing on the Install NuGet step
YAML
trigger:
- master
pool:
name: TestPool
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller#1
I got the following error
You are using a query match on the version string. Behavior changes or breaking changes might occur as NuGet updates to a new version. ERR:Client network socket disconnected before secure TLS connection was established
According to the YAML and error message, it seems that you are using self-hosted
agent and the error related to the TLS.
Since more and more Microsoft products/services are deprecating TLS 1.0 and 1.1, you need to ensure your applications to be working well using TLS 1.2.
You could use the following script to check if the TLS is ok.
(Invoke-WebRequest -Uri status.dev.azure.com).StatusDescription
If it does not OK, you need to enable the TLS 1.2 in your self-hosted agent.
And try to use the specific nuget version.
- task: NuGetToolInstaller#1
inputs:
versionSpec: 4.x
checkLatest: true
I am trying to build a UWP app using the latest version of windows for my vmImage, currently the build script looks like this:
Build script Code
# Universal Windows Platform
# Build a Universal Windows Platform project using Visual Studio.
# Add steps that test and distribute an app, save build artifacts, and more:
# https://aka.ms/yaml
trigger:
- none
pool:
vmImage: 'windows-2019'
variables:
solution: '**/*.sln'
buildPlatform: 'ARM'
buildConfiguration: 'Release'
appxPackageDir: '$(build.artifactStagingDirectory)\AppxPackages\\'
And whenever I try to use a vmImage to use windows-latest or windows-2022 it gives me multiple Error CS0234 for namespace Windows, System and many more things, is it possible to build UWP apps using windows-2022? Or am I missing something.
Other people have mentioned they solved their problem but their platform was ARMx64 and the solution did not apply to my problem
The issue is described here.
TLDR;
I have a repository with .NET Solution Containing WPF application and WAP project. I created a pipeline to build the solution. The pipeline definition yaml file contains:
trigger:
- master
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller#1
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
- task: VSBuild#1
inputs:
solution: '$(solution)'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
When the pipeline runs in the build step I receive an error:
##[error]C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VisualStudio\v16.0\AppxPackage\Microsoft.AppXPackage.Targets(823,5): Error : No certificate found with the supplied thumbprint: 7FA3B996D434F774830FF22AE1A157751AFB419E
It is difficult to know the specific cause of this problem, so please try the following:
As the error message says, the error is most likely due to your certificate. Try to generate a new certificate or cancel certificate validation.
Check your .sln file. If it has PackageCertificateThumbprint or PackageCertificateKeyFile parameter, check that it is configured correctly and that you have uploaded the correct certificate file to the appropriate path. Or try to delete the parameter and see if the problem is solved.
Make sure that the agent windows-latest has all the .NET SDK versions you need and all the software your project needs to reference. If not, use the task or command line to download them. Click this link to view the software installed on the windows-latest agent.
Try to run the build project locally. If it is successful, try using the self-hosted Agent. Click this document for detailed steps.
My Wpf app version is .net 5 and I had the same problem.I fixed it in this way in Azure Devops pipeline :
first I removed AppxPackageSigningEnabled and PackageCertificateThumbprint from wapproj file then I installed Code Signing task from azure devops marketplace and then add this task to my build pipeline after msbuild task. it signed my msix without problem.below picture is just a test and of course password should not be visible in not testing case.
In my company earlier we have executed RF scripts in Jenkins via Github. Now they have moved to Azure Devops.
I am new to Azure Devops. Could some provide the steps for the configuration and how to run
From your description , it seems that your Source Code is on Github.
Here are the steps to run the RF scripts:
Create a pipeline and use the repo from Github resource. You may need to create the connection to Github, then you could get the repos.
Add Use Python Version task to specify the required python version.
Install the Robot framework dependencies with Powershell task or Command Line Task.
Run the RF script with Powershell task or Command Line Task.
For example: Yaml Editor
trigger:
- master
jobs:
- job: 'Test'
pool:
vmImage: 'vs2017-win2016'
steps:
- task: UsePythonVersion#0
inputs:
versionSpec: '3.7'
architecture: 'x64'
- script: pip install robotframework robotframework-seleniumlibrary && npm install chromedriver
displayName: 'Install dependencies'
- powershell: robot --pythonpath . -x outputxunit.xml TestCases.robot
displayName: 'Run Robot Scripts'
If you want to use Pipeline Classic Editor, you could refer to this blog.
Hope this helps.
In Azure DevOps Server (version 2019.0.1) running on a Windows Server 2019 agent, with the 'Allow duplicates to be skipped' option selected for NuGet push task, a warning is displayed:
The 'Allow duplicates to be skipped' option is currently only available on Azure Pipelines. If NuGet.exe encounters a conflict, the task will fail.
The task results in the following error that causes the task to fail indicating that the above warning applies:
Response status code does not indicate success: 409 (Conflict - The feed already contains 'MyPackage X.Y.Z'. (DevOps Activity ID: 1A57312F-3C56-4E4D-9E78-73C7072A288F)).
I'm wondering if this issue is particular to Azure DevOps Server (rather than Azure DevOps Services), or if I'm doing something wrong, or if there is another workaround. I noticed someone else has the same issue from this comment on another question where it was mentioned that the option was available after someone asked how to ignore error 409 (duplicate package).
I would like to ignore duplicate packages using the NuGet task and ideally the 'Allow duplicates to be skipped' option on Azure DevOps Server. I'm aware that it could be resolved using scripting, but I'd prefer to avoid that if possible. Any help appreciated.
I don't know about the Azure DevOps task, but if you upgrade to nuget.exe 5.1, you can use the new -SkipDuplicate option. This should work for any NuGet server that correctly implements the NuGet protocol and on any CI server/agent.
If you're using the NuGetCommand#2 Azure Pipelines task, you can use the allowPackageConflicts parameter.
allowPackageConflicts
It allows the task to report success even if some of your packages are rejected with 409 Conflict errors.
This option is currently only available on Azure Pipelines and using Windows agents. If NuGet.exe encounters a conflict, the task will fail. This option will not work and publish will fail if you are within a proxy environment.
— https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/package/nuget
If you switch to azure pipelines (it seems it's the new way of doing things) you can use dotnet commands.
the option --skip-duplicate will be available in dotnet core 3.1 (still in preview) for the dotnet nuget push command (no need to use NuGet command as it's already available in dotnet).
But you can use it now if you install the latest .NET Core.
For example, this is a stage that will grab whichever nuGet you've got in a specific folder, install the latest dotnet core that supports the skip duplicates and push it to the repository feed.
- stage:
displayName: 'Release'
condition: succeeded()
jobs:
- job: 'Publish'
displayName: 'Publish nuGet Package'
steps:
- download: current
artifact: $(PIPELINE_ARTIFACT_NAME)
displayName: 'Download pipeline artifact'
- script: ls $(PATH_PIPELINE_ARTIFACT_NAME)
displayName: 'Display contents of downloaded articacts path'
- task: NuGetAuthenticate#0
displayName: 'Authenticate in NuGet feed'
- task: UseDotNet#2
displayName: 'Use .NET Core sdk 3.1 (preview)'
inputs:
packageType: sdk
version: '3.1.100-preview2-014569'
installationPath: $(Agent.ToolsDirectory)/dotnet
- script: dotnet nuget push $(PATH_PIPELINE_ARTIFACT_NAME)/**/*.nupkg --source $(NUGET_FEED) --api-key $(NUGET_API_KEY) --skip-duplicate
displayName: 'Uploads nuGet packages'