Having more than one project in a Visual Studio solution may introduce modularity and improve the maintainability of the code, but results in a more complicated build process.
In Azure DevOps, an MSBuild task can be used to build a Visual Studio solution containing one or many projects. This post shows two different ways of using the task to create a build artifact.
Option One
When creating an artifact this way, each project will be packaged into a separate zip archive.
The benefit of this approach is that different projects may be released in different Release pipelines, to different environments, with different frequency. The downside is that in case of adding a new project to the solution, it has to be added to each Release pipeline and stage manually.
To build the solution this way, the following MSBuild parameters can be used:
/p:DeployOnBuild=true
/p:WebPublishMethod=Package
/p:PackageAsSingleFile=true
/p:SkipInvalidConfigurations=true /p:PackageLocation="$(Build.ArtifactStagingDirectory)\\" Note the double trailing backslash coming after $(Build.ArtifactStagingDirectory). If you use only one, the task will fail as the end quote will be escaped.
Option Two
This option results in one directory containing files from all projects. It is useful when all the projects are to be released simultaneously. Also, in case of a new project, no changes need to be made to the Release pipeline.
This result is produced by running the MSBuild task with these parameters:
/p:DeployOnBuild=True
/p:DeployDefaultTarget=WebPublish
/p:WebPublishMethod=FileSystem
/p:SkipInvalidConfigurations=true /p:publishUrl="$(Build.ArtifactStagingDirectory)\\" Note the double trailing backslash coming after $(Build.ArtifactStagingDirectory). If you use only one, the task will fail as the end quote will be escaped.
There is one important thing to remember when using this option. If the created artifact is deployed to an Azure App Service using Azure DevOps, the Run from Package feature may get turned on for the target App Service. If not done intentionally, this will simply render the App Service unusable. To turn the feature off, remove the WEBSITE_RUN_FROM_PACKAGE application setting from the App Service in Azure Portal under the Configuration tab:
To prevent the feature from being switched on, the Web Deploy deployment method has to be specified in the Azure App Service deploy task:
You can read more about the issues caused by the Run from Package feature here, here, and here.
Publishing the artifact
To actually produce the artifact, the Publish build artifacts task can be used to publish the directory specified in the build tasks. In the examples shown above, that directory is represented by the built-in variable $(Build.ArtifactStagingDirectory).
Cover photo by Karl Groendal on Unsplash