Azure Devops Build Pipeline - files are not published - azure-devops

I'm trying to publish my application using a VS publish profile. When I publish through Visual Studio it works successfully, but through DevOps the publish does not work. The build is successful in both. Here is my VSBuild task definition:
inputs:
solution: '$(solution)'
msbuildArgs: '/t:Restore /p:DeployOnBuild=true /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:PublishBaseUrl=$(build.artifactstagingdirectory)'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'

Try to use /p:publishUrl instead of /p:PublishBaseUrl. If it still doesn't work, share your pubxml file and DevOps build log.

You are using publish profile, so you could specify the MSBuild argument like this: /p:DeployOnBuild=true /p:PublishProfile=myprofile
Related thread: Using msbuild to execute a File System Publish Profile

Related

Single WCF project will not create build artifact under YAML Azure DevOps Build Pipeline

Our build pipeline includes a YML template that is used to build all of our WCF services and Web applications. For all of the WCF services but one, it works like a charm. For this one WCF service, however, the following output is generated in the build logs during the Publish Artifact stage:
##[warning]Directory 'D:\azagent\A2_work\1381\a' is empty. Nothing will be added to build artifact 'drop'.
Our Build stage invokes a separate YML file which includes the following to build and publish the project:
- task: VSBuild#1
displayName: "Build ${{ parameters.solution}}"
inputs:
solution: ${{ parameters.solution }}
msbuildArgs: >
/p:DeployOnBuild=true
/p:WebPublishMethod=Package
/p:PackageAsSingleFile=true
/p:SkipInvalidConfigurations=true
/p:IgnoreDeployManagedRuntimeVersion=true
/p:PackageLocation="$(build.ArtifactStagingDirectory)"
platform: ${{ parameters.buildPlatform }}
configuration: ${{ parameters.buildConfiguration }}
- task: PublishBuildArtifacts#1
displayName: "Publish Build Artifact"
inputs:
PathtoPublish: "$(Build.ArtifactStagingDirectory)"
ArtifactName: "drop"
publishLocation: "Container"
As stated earlier, this works perfectly for all other WCF projects, and generates a build artifact. However, for the problematic WCF Service, no build artifact is generated. What we've observed is that no ZIP file is created in the D:\azagent\A2_work\1381\a folder (theoretically, Build.ArtifactStagingDirectory).
I have tried numerous recommended solutions to resolve this issue, all to no effect.
Adding a CopyFiles#2 task between the VSBuild#1 task and the PublishBuildArtifacts#1 task did place the files in the Build.ArtifactStagingDirectory, but they were not in a ZIP file. Further, the deployment task (later in the pipeline) failed because no ZIP file was present in the drop folder.
Adding /p:OutDir=$(Build.ArtfactStagingDirectory) did seem to produce some sort of artifact, but the deployment task still failed, claiming it could not find the ZIP file in the drop folder.
I created a test repo that contained only the WCF project (as it's normally contained in a solution containing it and a Web application) and ran the pipeline against that repo. No build artifact was created.
Ultimately, nothing I do seems to be able to get this project to generate a build artifact.
What am I missing here? What further information can I provide that will help you to help me resolve this issue?
According to Microsoft's Developer Community, this has been a known issue since August of 2019. WCF services built using a YAML pipeline do not produce build artifacts. Consequently, they cannot be deployed via YAML pipelines.
As of this date, there is neither a fix nor a workaround available from Microsoft.

Azure DevOps Builds the Solution Differently Than Visual Studio Locally

We are having a problem with Azure DevOps Build Pipelines producing different files than Visual Studio locally. Our Visual Studio 2019 solution has 24 C# based projects.
Some crucial DLLs (sites don’t work without them) that are being put into Bin folder when building the solution locally in Visual Studio are missing in when building the solution via Azure DevOps Build Pipelines. The missing DLLs do exist in packages.config.
Here is a screenshot of WinMerge showing that some files exist in Azure DevOps Build Pipelines and missing in Visual Studio locally and vice versa.
[
Azure DevOps YAML build task:
- task: VSBuild#1
inputs:
solution: 'Solution.sln'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
msbuildArgs: '/p:OutputPath="$(build.binariesDirectory)\Output\bin"'
How do we debug such behavior and make our builds exactly the same locally and in Azure DevOps?
I tested with default msbuildArgs in my .Net Core Web Application, and everything works fine.
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
I don't know why, but running MSBuild without any arguments fixed the problem. If somebody could shine some light on that behavior, that would be great!

Azure Pipelines No certificate found with the supplied thumbprint

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.

How to Publish a ClickOnce application with Azure DevOps Pipeline on different environments?

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

SpecFlow Example with azure-pipelines.yml for Azure DevOps

I am trying to get a simple SpecFlow+ example up and running on Azure DevOps.
Currently I get the following Error Message:
SpecFlow+LivingDoc: An error happened during the execution: The SDK
'Microsoft.NET.Sdk' specified could not be found.
How do I install the required "Microsoft .NET Test SDK 15"?
Can somebody point me to a simple example SpecFlow setup for Azure DevOps?
All details can be found on this public Azure DevOps project:
https://dev.azure.com/FlorianBoehmak/_git/SpecFlowCalculator
EDIT
Thanks #Levi Lu-MSFT for pointing me into the right direction. I put everything together into a github repository (including a devops generator). Enjoy :-)
https://github.com/fnbk/SpecFlowCalculator
In the yaml pipeline definition, it seems that the vstest task didnot specify the test .dll file. You can try specifying the test dlls like below.
- task: VSTest#2
inputs:
testAssemblyVer2: |
**\Calculator.Spec.dll
!**\obj\**
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
And if your project is a .net core project, the Project file path field in the SpecFlow+
is the path containing your project, not the project itself. You can try setting the projectfilepath to you root directory of your source repo like below.check here
- task: SpecFlowPlus#0
inputs:
projectFilePath: '$(System.DefaultWorkingDirectory)'
projectLanguage: 'en'
Hope above can be of some help!