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.
Related
I'm trying to set up a simple CI pipeline in Azure Devops
I have found it super easy to to do a Build -> Publish from within VS2019 to an Azure App Service, and it works flawlessly.
However, when trying to set up a CI pipeline which does the exact same thing from Azure Devops, I am presented with a YAML file, and options which I can drop into it.
I managed to get my pipeline to reach the "build" part, but then it couldn't find my custom nuget feed, so I updated my yaml to include this nuget restore:
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
variables:
buildConfiguration: 'Release'
steps:
- task: NuGetCommand#2
inputs:
command: 'restore'
restoreSolution: '**/*.sln'
feedsToUse: 'select'
vstsFeed: 'feed-id'
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
But the build fails again, with this error:
##[error]The nuget command failed with exit code(1) and error(Unable to load the service index for source https://MYVSTSADDRESS.pkgs.visualstudio.com/_packaging/THE_GUID/nuget/v3/index.json.
My question is, can't I just import the exact process that I follow from vs 2019?
Why is it so annoyingly complicated to do the exact same thing from devops?
Why would I need to complete this YAML document in devops, if its not required from VS??
##[error]The nuget command failed with exit code(1) and error(Unable to load the service index for source https://MYVSTSADDRESS.pkgs.visualstudio.com/_packaging/THE_GUID/nuget/v3/index.json.
From the URL in the error message, it seems that the task is using the Organization Scope Feed.
Based on my test, some pipeline settings will affect the use of this feed.
First, please check if your error message is similar to the following：
If yes, you could check the Limit job authorization scope to current project for non-release pipelines option is Enabled in Project Settings -> Pipelines.
You could try to disable the option.
Note: To disable this option, you need to disable the option in Organization Settings-> Settings first. Then you could disable the option in Project level.
Then you could navigate to Artifacts -> Feed Settings -> Permissions->... to enable the option Allow Project-Scoped builds.
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.
I try for several days now to publish my ClickOnce application with Azure DevOps Pipeline. Before going in detail here is what I would like to do from my release view:
I started with one artifact and 2 release stage modifying the config.deploy file with staging variables during my Staging stage and modifying the config.deploy file with production variables during my Production stage. Deployment was working fine but installation of application was not working because of hash check system.
So I decided to create 2 builds with 2 artifacts. I renamed the classic drop by a drop_staging during my first build and drop_production for my second build. I was hoping the build system (MSBuild) was able to select the correct app.Debug.config then app.Release.config file during the build and publish process.
Here is my build definition
Here is my build arguments
/target:publish
/p:ApplicationVersion=$(Build.BuildNumber)
/p:PublishURL=http://app-staging.example.com/
/p:UpdateEnabled=true
/p:UpdateMode=Foreground
/p:ProductName="App Staging"
/p:OutputPath="$(build.ArtifactStagingDirectory)\Publish\\"
Configuration is set to Staging for first build then on Production for second build. I have, of course, a Staging and Production build definition in visual Studio. I have an app.config with app.Staging.config and app.Production.config in my project.
I cannot simply add a task to transform my config file after the build because I will not respect the hash. I should find a way to say to my build to use the correct XML transformation config file. I don't see any other solution or maybe applying this transformation before the build? Is it possible? What are your solutions?
finally I could solve this by adding a file transform before my build.
In case you need more help here is my YAML detail for transformation
steps:
- task: FileTransform#1
displayName: 'File Transform: '
inputs:
folderPath: App.Example
enableXmlTransform: true
xmlTransformationRules: '-transform **\*.Staging.config -xml **\*.config'
fileType: xml
#Your build pipeline references the ‘BuildPlatform’ variable, which you’ve selected to be settable at queue time. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab, and then select the option to make it settable at queue time. See https://go.microsoft.com/fwlink/?linkid=865971
steps:
- task: VSBuild#1
displayName: 'Build solution'
inputs:
solution: Example.sln
msbuildArgs: '/target:publish /p:ApplicationVersion=$(Build.BuildNumber) /p:PublishURL=http://staging.example.com/ /p:UpdateEnabled=true /p:UpdateMode=Foreground /p:ProductName="App Staging" /p:OutputPath="$(build.ArtifactStagingDirectory)\Publish\\"'
platform: '$(BuildPlatform)'
configuration: Staging
To add to the build solution stage, you can use your visual studio Publish profile as shown below on the msbuildArgs. Please note this doesn't do the version incrementation for you
- task: VSBuild#1
displayName: 'Publish Project'
inputs:
solution: '$(projectSolution)'
msbuildArgs: '/target:publish /p:ApplicationRevision=$(applicationRevision) /p:PublishProfile="Application/PublishProfiles/HerbalPublishProfile.pubxml" /p:PublishDir="$(build.ArtifactStagingDirectory)\Publish\\"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
msbuildArchitecture: x64
I have 2 ways to build a pipeline on Azure DevOps, with YAML pipeline template or with Tasks preset in Classic Editor(which can be converted into Task Group as well).
If I select the same template in either one of these ways, the same task in the Classic Editor could be missing from its YAML pipeline template counterpart.
I selected .NET Desktop with both ways.
https://i.imgur.com/2fGcZ14.png
In Classic Editor, I could see 2 of these publishing tasks as seen below.
https://i.imgur.com/yxYxD44.png
With YAML Pipeline, the 2 tasks seen above are missing though.
# .NET Desktop
# Build and run tests for .NET Desktop or Windows classic desktop solutions.
# Add steps that publish symbols, save build artifacts, and more:
# https://learn.microsoft.com/azure/devops/pipelines/apps/windows/dot-net
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)'
- task: VSTest#2
inputs:
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
I can't figure out why this is happening though. Appreciate some help or pointers on this, thanks in advance.
Both those tasks are not missing, but you might need to manually add them.
Publishing artifacts is no long a standalone task, it's become part of the core capability of YAML pipelines, so it's effective a native step called publish
steps:
- publish: output/files # path to files/directory containing files you want to publish
artifact: myartifact # Name of the artifact
As for copy files, that's still a task, as documented here
The docs for YAML pipelines are pretty good IMO
As well as a complete reference for the all the built-in tasks
I'm trying to to create a yaml definition file for a simple CI/CD pipeline in Azure DevOps.
My pipeline should look like this:
Is it possible to define the whole workflow in one definition file with different stages and jobs?
How can I determine which project (which GIT sub-path has triggered the build) has changed to proceed with project A/B workflow?
The first workflow with project A seems feasible for me. I can run the sc command together with runsas or psexec to start/stop the service and use a copy file task. But how can I initiate to publish the ASP.NET web application to a local directory (as I would do with VS->Publish->Local Folder)?
After that I guess it's the easiest way to make use of scripts to replace content, install npm packages to minify and bundle js/css files and upload these to a ftp server. Or any better/easier ideas?
If you guys can support me by creating an initial yaml definition just for the workflow without the details of the tasks I would really appreciate that. Maybe I get a more clear vision if you can answer my questions above.
At the moment I have a very simple initial build file:
# ASP.NET
# Build and test ASP.NET projects.
# Add steps that publish symbols, save build artifacts, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/apps/aspnet/build-aspnet-4
trigger:
- master # for a productive deployment after manual approval
- develop # for a automatic test deployment
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller#0
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
feedsToUse: 'select'
vstsFeed: 'tpcemedia'
- task: VSBuild#1
inputs:
solution: '$(solution)'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
No, releases are not yet possible in yaml. You can have build stages\jobs, but it makes no sense to use them in such a simple case
Yaml has a path-trigger filter, just configure a build per application. no need to complicate the build with conditions. do something like this:
build1:
trigger:
paths:
include: src/proj1/*
build2:
trigger:
paths:
include: src/proj2/*
Better to separate release and build, this way your release agent will be directly on the server and would be able to restart service locally without the need to have network access (and its more secure). It would also pull the artifacts generated by the build agent "for free".
Why use ftp, just use "publish artifacts" step(s), much easier.