dotnet build application deploy

Question

We have a .net core web application and we're building an automatic deploy process. From what I've read on this site, I've seen that:

the product of dotnet build isn't ready to be transferred to another machine to run. This is in contrast to the behavior of the .NET Framework in which building an executable project (an application) produces output that's runnable on any machine where the .NET Framework is installed.

So if I have .net core runtime installed on the target machine, is it ok to use the output of the build command? Because with this command, the output doesn't contain the extra folders (localization dll's, runtime folder, etc)...

Also, is there a parameter that I can use with dotnet build command so that in the output folder to be only MyStartupProject.runtimeconfig.json and not all runtimeconfig.json files(from all the projects and also the version of runtimeconfig.dev.json)?

Answer 1

tl;dr

dotnet publish will do what you want

---

The dotnet publish command will do a full package of your application, ready to be run on a UAT or Production environment.

Please note

the link in the previous paragraph .NET Core 2.x, but the process is very similar for .NET Core 1.x. The linked page includes instructions for both .NET Core 1.x and 2.x in a series of tabs.

There are a couple of possible arguments for the publish command, and these will depend on how you want to host your application. For instance --self-contained will package the relevant .NET Core run time with your application, so that it can be pushed to a server "as is" without having to install the run time.

The -r|--runtime <RUNTIME_IDENTIFIER> can be useful, too. The documentation (linked earlier) explains it in the following way

Publishes the application for a given runtime. This is used when creating a self-contained deployment (SCD). For a list of Runtime Identifiers (RIDs), see the RID catalog. Default is to publish a framework-dependent deployment (FDD).

You'll also want to think about using the --configuration switch, supplying either Debug or Release - preferably Release. This will essentially do the same as building in either Debug or Release within Visual Studio, except this will happen before the publish action.

Here's the description of the dotnet publish command from the official documentation:

dotnet publish compiles the application, reads through its dependencies specified in the project file, and publishes the resulting set of files to a directory. The output will contain the following:

• Intermediate Language (IL) code in an assembly with a dll extension.
• .deps.json file that contains all of the dependencies of the project.
• .runtime.config.json file that specifies the shared runtime that the application expects, as well as other configuration options for the runtime (for example, garbage collection type).

The application's dependencies. These are copied from the NuGet cache into the output folder.

The dotnet publish command's output is ready for deployment to a hosting system (for example, a server, PC, Mac, laptop) for execution and is the only officially supported way to prepare the application for deployment. Depending on the type of deployment that the project specifies, the hosting system may or may not have the .NET Core shared runtime installed on it. For more information, see .NET Core Application Deployment. For the directory structure of a published application, see Directory structure.