deployment - .NET Core - how does the 'dotnet publish' command work?

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

I have a solution with some projects targeting .NET Standard 2.0 and a console application project targeting .NET Core 2.1.

I set "myFolder" as the output folder. Building from Visual Studio, I get all DLL files in:

"myFolder\netstandard2.0"

"myFolder\netcoreapp2.1"

I get the same using the "dotnet build" command. Now I need my console application's EXE file. So I use the "dotnet publish -c Release -r win-x64 MySolution.sln" command.

Now I get this new directory, "myFolder\netcoreapp2.1\win-x64", where I find all DLL files and the console application's EXE file.

Not enough!

I find one directory more, "myFolder\netcoreapp2.1\win-x64\publish", where I find again all DLL files and the console application's EXE file.

Which meaning do they have? I read the command documentation , but I didn't find my answer.

With .NET CORE 3.0 this is simplified, Checkout this post: stackoverflow.com/a/56710981/6441150 – Gopi Jun 21, 2019 at 22:11 There being a copy of the files inside and outside the publish folder still happens in .NET5 – PandaWood Mar 15, 2022 at 22:05

-o|--output <OUTPUT_DIRECTORY>

Specifies the path for the output directory. If not specified, it defaults to ./bin/[configuration]/[framework]/publish/ for a framework-dependent deployment or ./bin/[configuration]/[framework]/[runtime]/publish/ for a self-contained deployment.

dotnet publish -c Release -r win-x64 --output ./MyTargetFolder MySolution.sln

All you really need to understand to be able to successfully publish and deploy is that you need to dotnet publish and ensure that you have a Release configuration -c Release , as well as any other required options on the command line.

All of your files will be in the 'publish' subfolder, e.g. ./bin/Release/[framework that your solution is targeting]/publish . The files contained here are everything that is needed for a running instance of your application/service. The MySolution.dll is the entry point for your app/service, and will automatically link to all of the other dependencies and configuration stored in the publish folder.

To configure and deploy a running instance, you need to work out how to deploy all of those files to a server, and somehow configure something (e.g. a web server, runtime, service host ...) to call your MySolution.dll .

Note that in your dotnet publish you're specifying -r , which means that your application is targetted to run under 64 bit Windows, as opposed to a Linux distribution or OS X (which makes it less portable, but it has the advantage of isolating your application from changes to an installed runtime on a server that you deploy it to.). That's why you're seeing an extra folder win-x64 .

Also you're explicitly building from the solution configuration specified by your solution file MySolution.sln , which is probably the most reliable thing to do as this will ensure that any projects used as dependencies by your solution (which is a typical good practice) will be included in the build/publish.

I think something that puzzled original poster (and currently has me puzzled) is that the publish command creates a folder with all the dlls, plus within that three folders (properties, publish, runtimes) and that inner publish folder has all the dlls again. That's a little confusing! – Alex White Apr 20, 2020 at 15:21

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question . Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers .