Answers: <p>I'm looking this fact:</p>
  
  <blockquote>
    <p>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.</p>
  </blockquote>
  
  <p>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 <code>dotnet build</code> instead of using VSBuild. </p>
  
  <p>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 <code>dotnet build</code> in <code>DotNetCoreCLI@2</code> task, because <code>VSBuild</code> task only runs on Windows based agent, not Ubuntu and it is intended to compile .NET Framework and other platform other than .NET Core.</p>
  
  <p>Please consult the official doc of DotNetCoreCLI@2 task at <a href="https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops" rel="nofollow noreferrer">https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops</a></p>
  
  <p>After you use <code>dotnet build</code>, use <code>dotnet publish</code> to publish your artifact. It is much easier and it's also the best way to publish .NET Core apps.</p>
  
  <p>I have sample usage of <code>dotnet build</code> and <code>dotnet publish</code> of this on my repo: 
  <a href="https://github.com/eriawan/dotnetcore-cicd-samples/blob/master/yaml-samples/sample_pipelines_check.yml" rel="nofollow noreferrer">https://github.com/eriawan/dotnetcore-cicd-samples/blob/master/yaml-samples/sample_pipelines_check.yml</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2019-11-01T16:45:37.507Z
Answers: Thanks, this is what I was looking for. Everything in the pipeline was adapted very quickly.
Answers: Ned Flanders
Answers: CC BY-SA 4.0
Answers: 2020-09-04T20:38:43.703Z
Answers: I am having the same sort of issue, but for a asp.net web app
Answers: bitshift
Answers: CC BY-SA 4.0
Answers: 2019-11-01T09:54:26.170Z
Answers: 2019-11-01T10:13:52.080Z
Answers: 2019-11-01T10:13:52.080Z
Answers: Eriawan Kusumawardhono
Body: <p>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.</p>
  
  <p>In the Build Pipeline, the solution is built and afterward published to the <em>ArtifactStagingDirectory</em>.</p>
  
  <pre><code>- 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'
  </code></pre>
  
  <p>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:</p>
  
  <blockquote>
    <p>/drop/MyProject.20191028.2.49/Content/d_C/a/1/s/MyProject/obj/Release/netcoreapp3.0/PubTmp/Out</p>
  </blockquote>
  
  <p>Is it possible to reduce this folder structure to something like this or even less?</p>
  
  <blockquote>
    <p>/drop/MyProject.20191028.2.49/Release/netcoreapp3.0/</p>
  </blockquote>
  
  <hr>
  
  <p>At the moment, I am working around this in the release stage with a bash script.</p>
  
  <pre><code>drop=$(find /MyProject/Release/drop/MyProject.$(build.BuildNumber).$(Build.BuildId)/ -name "Out")
  
  ln -s $drop /MyProject/Release/Current
  </code></pre>
  
  <p>In general, I am fine with this, but a little cleaner solution would be nice :)</p>
  
  <p>*The application will be ported to .NET Core 3.1 as soon as it gets released. If this is relevant.</p>
  
Tags: <azure-devops><linux><artifacts>
Title: Azure DevOps Artifact.zip folder structure for .NET Core 3.0 application
UserDisplayName: Ned Flanders
ThreadText: # Azure DevOps Artifact.zip folder structure for .NET Core 3.0 application
  
  (Asked by: username_0 on 2019-10-28)
  
  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*.
  
  ```
  - 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/Current
  
  ```
  
  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.
  
  **Tags:** azure-devops, linux, artifacts
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-11-01. Score: 3 | Accepted answer
  
  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 `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/username_1/dotnetcore-cicd-samples/blob/master/yaml-samples/sample_pipelines_check.yml>
  
  > **Comments:**
  > **username_0**: Thanks, this is what I was looking for. Everything in the pipeline was adapted very quickly.  
  > **username_2**: I am having the same sort of issue, but for a asp.net web app  
  
  ---
  
  