patternMinor
Azure DevOps Artifact.zip folder structure for .NET Core 3.0 application
Viewed 0 times
artifactcoreapplicationzipazurefolderstructurefornetdevops
Problem
I have an ASP.NET Core 3.0 application for which I have a full CI/CD setup in Azure DevOps. The Application is hosted on a Ubuntu 18.04 server machine.
In the Build Pipeline, the solution is built and afterward published to the ArtifactStagingDirectory.
This zip contains the complete folder structure of the server, which has IMHO nothing to do with the project. For me this is noise.
For example:
/drop/MyProject.20191028.2.49/Content/d_C/a/1/s/MyProject/obj/Release/netcoreapp3.0/PubTmp/Out
Is it possible to reduce this folder structure to something like this or even less?
/drop/MyProject.20191028.2.49/Release/netcoreapp3.0/
At the moment, I am working around this in the release stage with a bash script.
In general, I am fine with this, but a little cleaner solution would be nice :)
*The application will be ported to .NET Core 3.1 as soon as it gets released. If this is relevant.
In the Build Pipeline, the solution is built and afterward published to the ArtifactStagingDirectory.
- task: VSBuild@1
inputs:
solution: '$(solution)'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)\MyProject.$(build.BuildNumber).$(Build.BuildId).zip"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
- task: PublishBuildArtifacts@1
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop'
publishLocation: 'Container'This zip contains the complete folder structure of the server, which has IMHO nothing to do with the project. For me this is noise.
For example:
/drop/MyProject.20191028.2.49/Content/d_C/a/1/s/MyProject/obj/Release/netcoreapp3.0/PubTmp/Out
Is it possible to reduce this folder structure to something like this or even less?
/drop/MyProject.20191028.2.49/Release/netcoreapp3.0/
At the moment, I am working around this in the release stage with a bash script.
drop=$(find /MyProject/Release/drop/MyProject.$(build.BuildNumber).$(Build.BuildId)/ -name "Out")
ln -s $drop /MyProject/Release/CurrentIn general, I am fine with this, but a little cleaner solution would be nice :)
*The application will be ported to .NET Core 3.1 as soon as it gets released. If this is relevant.
Solution
I'm looking this fact:
I have an ASP.NET Core 3.0 application for which I have a full CI/CD setup in Azure DevOps. The Application is hosted on a Ubuntu 18.04 server machine.
Therefore I can safely assume that you are developing ASP.NET Core 3.0 app to be hosted in Ubuntu. Any .NET Core 3.0 (or later) application means that you should rely on the
Also you had stated that you will host the app on Ubuntu 18.x, then you should also run the build on Azure DevOps agent that runs on Ubuntu. This means you should only use
Please consult the official doc of DotNetCoreCLI@2 task at https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops
After you use
I have sample usage of
https://github.com/eriawan/dotnetcore-cicd-samples/blob/master/yaml-samples/sample_pipelines_check.yml
I have an ASP.NET Core 3.0 application for which I have a full CI/CD setup in Azure DevOps. The Application is hosted on a Ubuntu 18.04 server machine.
Therefore I can safely assume that you are developing ASP.NET Core 3.0 app to be hosted in Ubuntu. Any .NET Core 3.0 (or later) application means that you should rely on the
dotnet build instead of using VSBuild. Also you had stated that you will host the app on Ubuntu 18.x, then you should also run the build on Azure DevOps agent that runs on Ubuntu. This means you should only use
dotnet build in DotNetCoreCLI@2 task, because VSBuild task only runs on Windows based agent, not Ubuntu and it is intended to compile .NET Framework and other platform other than .NET Core.Please consult the official doc of DotNetCoreCLI@2 task at https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops
After you use
dotnet build, use dotnet publish to publish your artifact. It is much easier and it's also the best way to publish .NET Core apps.I have sample usage of
dotnet build and dotnet publish of this on my repo: https://github.com/eriawan/dotnetcore-cicd-samples/blob/master/yaml-samples/sample_pipelines_check.yml
Context
StackExchange DevOps Q#9598, answer score: 3
Revisions (0)
No revisions yet.