如何在VSTS构建与发布中选择解决方案配置

Got it, let’s walk through exactly how to pick your target configuration (and its corresponding Settings.*.xml file) in both VSTS build and release pipelines. I’ll break this into two clear sections since each pipeline type handles configuration selection a bit differently.

Build Pipeline Setup #

First, we’ll make the build pipeline let you choose a configuration at trigger time, then map that choice to the correct settings file.

1. Add a Configuration Dropdown Variable

   • Go to your build pipeline’s Variables tab.
   • Create a new variable named BuildConfiguration (you can pick any name, but this is standard).
   • Set the variable type to Dropdown, then add the options: Debug, Release, Custom. Set your preferred default (like Release).
   • Make sure the variable is marked as Settable at queue time so you can pick the config when you manually trigger a build.

2. Pass the Configuration to Your Build Task

   • If you’re using MSBuild (most .NET projects), edit your MSBuild task’s Arguments field to include:

     /p:Configuration=$(BuildConfiguration)
     

   • This tells MSBuild to compile using the selected configuration (e.g., Debug, Release).

3. Copy & Rename the Corresponding Settings File

   • Add a Copy Files task after your build task:
     • Source folder: The root of your project where the Settings.*.xml files live (e.g., $(System.DefaultWorkingDirectory)/YourProject).
     • Contents: Settings.$(BuildConfiguration).xml (this dynamically picks the right file based on your selection).
     • Target folder: $(Build.ArtifactStagingDirectory) (the folder where build artifacts are stored for publishing).
   • Add a Rename Files task right after:
     • Source folder: $(Build.ArtifactStagingDirectory)
     • Files: Settings.$(BuildConfiguration).xml
     • New name: Settings.xml
   • This ensures the correct settings file is renamed to the standard Settings.xml that your app expects, so it gets packaged into your build artifact.

For YAML Build Pipelines #

If you’re using YAML instead of the classic editor, here’s how to implement the same logic:

variables:
  - name: BuildConfiguration
    type: string
    values:
      - Debug
      - Release
      - Custom
    default: Release
    # Allow changing this variable when queuing the build
    isSecret: false
    isSettable: true

steps:
  # Build the project with the selected configuration
  - task: MSBuild@1
    inputs:
      solution: '**/*.sln'
      msbuildArguments: '/p:Configuration=$(BuildConfiguration)'

  # Copy the correct settings file to the artifact staging directory
  - task: CopyFiles@2
    inputs:
      SourceFolder: '$(System.DefaultWorkingDirectory)/YourProject'
      Contents: 'Settings.$(BuildConfiguration).xml'
      TargetFolder: '$(Build.ArtifactStagingDirectory)'

  # Rename to Settings.xml so the app uses it
  - task: RenameFiles@1
    inputs:
      SourceFolder: '$(Build.ArtifactStagingDirectory)'
      Files: 'Settings.$(BuildConfiguration).xml'
      NewName: 'Settings.xml'

  # Publish the artifact for release
  - task: PublishBuildArtifacts@1
    inputs:
      PathtoPublish: '$(Build.ArtifactStagingDirectory)'
      ArtifactName: 'drop'
      publishLocation: 'Container'

Release Pipeline Setup #

If you need to switch configurations during release (instead of fixing it at build time), here’s how to handle it:

1. Add a Configuration Variable in the Release Pipeline

   • Go to your release pipeline’s Variables tab.
   • Create a ReleaseConfiguration dropdown variable with the same options: Debug, Release, Custom.
   • Mark it as Settable at release time so you can choose when triggering a release.

2. Swap the Settings File During Deployment

   • If you packaged all three Settings.*.xml files in your build artifact (adjust your build pipeline to copy all three instead of just one), add a Copy Files task in your release stage:
     • Source folder: $(System.DefaultWorkingDirectory)/drop (where your artifact is downloaded).
     • Contents: Settings.$(ReleaseConfiguration).xml
     • Target folder: The folder where your app is deployed (e.g., $(WebAppDeployDir) for IIS, or the root of your Azure App Service).
   • Add a Rename Files task to overwrite the existing Settings.xml with the selected one.

   Alternatively, if you only want to deploy the selected config’s settings file, you can pass the ReleaseConfiguration variable back to a re-build step in the release pipeline (but this is less common—most teams fix the config at build time).

Quick Notes #

• Double-check the file paths in your tasks to make sure they match where your Settings.*.xml files are stored in your repo.
• If you’re using variable substitution instead of file replacement, you can use the File Transform task to apply values from your pipeline variables to a base Settings.xml—but your current setup with separate files is simpler for distinct configurations.

Hope this helps you smoothly toggle between your Debug, Release, and Custom setups in VSTS! If you hit any specific issues with your pipeline (like task ordering or path mismatches), feel free to share more details.

内容的提问来源于stack exchange，提问作者Scarlet959