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

Question

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?

Schwaben

Answer 1

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

Schwaben

thank you very much this post saved my day! – Myology

First I didn't understand the content of the example code. But here is a good article about the transformation details: File transforms and variable substitution reference – Rondi

In fact a lot of this changed on Azure. This is no more up to date. – Schwaben

Answer 2

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

Crackup

Answer 3

Another possibility would be to disable hashing in the config file, under Publish section of your app properties:

This will allow you to update app.config file in release time, not being necessary to have multiple artifacts for each environment (Staging / Prod / etc.). This will also prevent your application to be signed but, as long as you don't require it, will do the trick.

Belkisbelknap