How do I integrate exe publishing with the VS2019 build of the console .net core 2.2 application?

Question

I saw a couple of similar questions but so far I found no single answer to the problem of integrating the publishing step with my build process. Unfortunately the dotnet publish command rebuilds the project again meaning that if I put the "dotnet publish" command in the project's Post-Build steps I get an infinite loop of building retries.

What I want to achieve is to get an exe built for my .NET Core 2.2 Console App for a few selected environments eg. osx and windows-10, possibly linux too, each in its own folder. Obvious condition is that it has to be integrated with the build, so no extra manuals steps (commands) are required. This has to work from within VS2019 Pro as well in CI (like AzureDevOps).

Is this basic step achievable or .Net core was a major step-back in the progress of software development? I hope I just miss something and I am just grossly exaggerating. :)

Thanks, Radek

Answer 1

How do I integrate exe publishing with the VS2019 build of the console .net core 2.2 application?

Actually, I think you do not need to worry about this.

dotnet publish already contains the build process. Publish process will first execute Build and then run publish. In a word, Build is a part of Publish process.

So when you input dotnet publish under Build, you will get an infinite loop of building retries.

Solution

----- Just delete post-build event in xxx.csproj file and just dotnet publish directly and it will run the build process first.

You can test in the local VS and when you right-click on your project-->Publish, it will show the step in the output windwow.

In addition, as far as I know, Azure DevOps has a task called dotnet publish which contains Build.

And if you want to do some msbuild custom target only for publish step, you can add a condition like Condition="'$(DeployOnBuild)'=='true'", it will execute for Publish process rather than the normal build step(right-click on your project-->Build).

<Target Name="testone" Condition="'$(DeployOnBuild)'=='true'" AfterTargets="Build">

    xxxxxxxxxxxxxx  

</Target>

---------------Update 1----------------

First question

Actually, the build of the publish is the pure process and then publish will copy the content of the build output into publish folder. So the execute program is just from the build output folder.

See the publish log:

So you should not specify a publish target under the build process. This is superfluous.

Second question

To generate this program for Window-10, linux or osx, you can try these command line to publish your project:(Release is the standard release build configuration)

For Win-10:

dotnet publish -r win10-x64 -c Release --self-contained

Linux:

dotnet publish -r linux-x64 -c Release --self-contained

For osx:

dotnet publish -r osx.10.12-x64 -c Release --self-contained

In this way, the project is first built according to the specified runtime and then published.

More info about .NET Core RID Catalog, you can refer to this document.

Update 2

I think you should change the configuration in this package UI:

Then click Save.

Also, when you publish this web project, please try to delete bin and obj folder and then publish it.

Debug: bin\Debug\netcoreapp2.1\publish

Release: bin\Release\netcoreapp2.1\publish

Or you should use dotnet command as I described to publish the project. The path is under Debug or Release folder.

Answer 2

What I want to achieve is to get an exe built for my .NET Core 2.2 Console App for a few selected environments eg. osx and windows-10, possibly linux too, each in its own folder. Obvious condition is that it has to be integrated with the build, so no extra manuals steps (commands) are required. This has to work from within VS2019 Pro as well in CI (like AzureDevOps).

Is this basic step achievable or .Net core was a major step-back in the progress of software development?

It's a good idea but as I know what you want is not 100% supported for now.

It seems that your expected scenario is:

Click the Build(F5) button=>Project will be built in different platforms win-x64,win-x86,linux-x64...,also will be published in different platforms automatically with self-contained mode.

But the fact is:

1.Click the Build button(Build(F5) equals to the Build button in project context) will run the Build Target (A default built-in target for each project for build). => dotnet build in command-line.

2.Click the Publish button will run the Publish Target (A default built-in target for each project for publish). => dotnet publish in command-line.

3.If you have any build/publish command in post-build event, it will result in an expected loop. So it's hard to combine publish with build perfectly since they're two actions in VS with different button/behavior/corresponding command. (Only dotnet publish command can recognize --self-contained)

4.To build/publish the projects in parallel, the batch file or msbuild targets file is a good choice.

#1.Build different platforms using one build command see this. #2.Publish different platforms using one command see this. (They both use custom .targets to do the job)

Suggestions:

According to your scenario, I think you can consider using #2. It's not necessary for you to build with different platforms during your normal development.

1.In local VS when you're developing and debugging:

The default build button/option is enough for you to debug.

2.In local VS when you want to publish the project in different platforms:

Use #2 above so that you can publish them using cmd.exe or PS.exe. (Via command dotnet msbuild -restore -t:PublishAllRids)

3.When you're automating the CI pipeline in AzDeops(Also use #2):

A CMD/PS task with dotnet msbuild -restore -t:PublishAllRids command is enough. Dotnet publish will build automatically if we don't pass --no-build argument.

4.Azure Devops Service suggests separate the jobs in different tasks, it's not recommend to Integrate Publish with Build heavily, especially for .net core projects. (Here's official sample about CI for .net core projects.)