<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>

CC BY-SA 4.0
2019-11-01T16:45:37.507Z
Thanks, this is what I was looking for. Everything in the pipeline was adapted very quickly.
Ned Flanders
CC BY-SA 4.0
2020-09-04T20:38:43.703Z
I am having the same sort of issue, but for a asp.net web app
bitshift
CC BY-SA 4.0
2019-11-01T09:54:26.170Z
2019-11-01T10:13:52.080Z
2019-11-01T10:13:52.080Z
Eriawan Kusumawardhono
<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>

<azure-devops><linux><artifacts>
Azure DevOps Artifact.zip folder structure for .NET Core 3.0 application
Ned Flanders
# 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/eriawan/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  

---

