52

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Lorenzo Isidori
  • 1,809
  • 2
  • 20
  • 31
  • 1
    With .NET CORE 3.0 this is simplified, Checkout this post: https://stackoverflow.com/a/56710981/6441150 – Gopi Jun 21 '19 at 22:11
  • There being a copy of the files inside and outside the publish folder still happens in .NET5 – PandaWood Mar 15 '22 at 22:05

2 Answers2

62

Per the documentation

-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

willwolfram18
  • 1,747
  • 13
  • 25
10

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Chris Halcrow
  • 28,994
  • 18
  • 176
  • 206
  • 12
    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 '20 at 15:21