1(1) .NET (1)
2
6 This article applies to: ✔️ .NET Core 2.1 SDK and later versions
7
9 dotnet publish - Publishes the application and its dependencies to a
10 folder for deployment to a hosting system.
11
13 dotnet publish [<PROJECT>|<SOLUTION>] [-a|--arch <ARCHITECTURE>]
14 [-c|--configuration <CONFIGURATION>]
15 [-f|--framework <FRAMEWORK>] [--force] [--interactive]
16 [--manifest <PATH_TO_MANIFEST_FILE>] [--no-build] [--no-dependencies]
17 [--no-restore] [--nologo] [-o|--output <OUTPUT_DIRECTORY>]
18 [--os <OS>] [-r|--runtime <RUNTIME_IDENTIFIER>]
19 [--self-contained [true|false]]
20 [--no-self-contained] [-v|--verbosity <LEVEL>]
21 [--version-suffix <VERSION_SUFFIX>]
22 dotnet publish -h|--help
24
26 dotnet publish compiles the application, reads through its dependencies
27 specified in the project file, and publishes the resulting set of files
28 to a directory. The output includes the following assets:
29 • Intermediate Language (IL) code in an assembly with a dll extension.
31 • A .deps.json file that includes all of the dependencies of the
33 project.
34 • A .runtimeconfig.json file that specifies the shared runtime that the
36 application expects, as well as other configuration options for the
37 runtime (for example, garbage collection type).
38 • The application’s dependencies, which are copied from the NuGet cache
40 into the output folder.
41 The dotnet publish command’s output is ready for deployment to a host‐
43 ing system (for example, a server, PC, Mac, laptop) for execution.
44 It’s the only officially supported way to prepare the application for
45 deployment. Depending on the type of deployment that the project spec‐
46 ifies, the hosting system may or may not have the .NET shared runtime
47 installed on it. For more information, see Publish .NET apps with the
48 .NET CLI.
49 Implicit restore
51 You don’t have to run dotnet restore because it’s run implicitly by all
52 commands that require a restore to occur, such as dotnet new, dotnet
53 build, dotnet run, dotnet test, dotnet publish, and dotnet pack. To
54 disable implicit restore, use the --no-restore option.
55 The dotnet restore command is still useful in certain scenarios where
57 explicitly restoring makes sense, such as continuous integration builds
58 in Azure DevOps Services or in build systems that need to explicitly
59 control when the restore occurs.
60 For information about how to manage NuGet feeds, see the dotnet restore
62 documentation.
63 MSBuild
65 The dotnet publish command calls MSBuild, which invokes the Publish
66 target. If the IsPublishable property is set to false for a particular
67 project, the Publish target can’t be invoked, and the dotnet publish
68 command only runs the implicit dotnet restore on the project.
69 Any parameters passed to dotnet publish are passed to MSBuild. The -c
71 and -o parameters map to MSBuild’s Configuration and PublishDir proper‐
72 ties, respectively.
73 The dotnet publish command accepts MSBuild options, such as -p for set‐
75 ting properties and -l to define a logger. For example, you can set an
76 MSBuild property by using the format: -p:<NAME>=<VALUE>.
77 You can also set publish-related properties by referring to a .pubxml
79 file (available since .NET Core 3.1 SDK). For example:
80 dotnet publish -p:PublishProfile=FolderProfile
82 The preceding example uses the FolderProfile.pubxml file that is found
84 in the <project_folder>/Properties/PublishProfiles folder. If you
85 specify a path and file extension when setting the PublishProfile prop‐
86 erty, they are ignored. MSBuild by default looks in the Proper‐
87 ties/PublishProfiles folder and assumes the pubxml file extension. To
88 specify the path and filename including extension, set the PublishPro‐
89 fileFullPath property instead of the PublishProfile property.
90 The following MSBuild properties change the output of dotnet publish.
92 • PublishReadyToRun
94 Compiles application assemblies as ReadyToRun (R2R) format. R2R is a
96 form of ahead-of-time (AOT) compilation. For more information, see
97 ReadyToRun images. Available since .NET Core 3.0 SDK.
98 To see warnings about missing dependencies that could cause runtime
100 failures, use PublishReadyToRunShowWarnings=true.
101 We recommend that you specify PublishReadyToRun in a publish profile
103 rather than on the command line.
104 • PublishSingleFile
106 Packages the app into a platform-specific single-file executable.
108 For more information about single-file publishing, see the single-
109 file bundler design document (https://github.com/dotnet/de‐
110 signs/blob/main/accepted/2020/single-file/design.md). Available
111 since .NET Core 3.0 SDK.
112 We recommend that you specify this option in the project file rather
114 than on the command line.
115 • PublishTrimmed
117 Trims unused libraries to reduce the deployment size of an app when
119 publishing a self-contained executable. For more information, see
120 Trim self-contained deployments and executables. Available since
121 .NET Core 3.0 SDK as a preview feature.
122 We recommend that you specify this option in the project file rather
124 than on the command line.
125 For more information, see the following resources:
127 • MSBuild command-line reference
129 • Visual Studio publish profiles (.pubxml) for ASP.NET Core app deploy‐
131 ment
132 • dotnet msbuild
134 Workload manifest downloads
136 When you run this command, it initiates an asynchronous background
137 download of advertising manifests for workloads. If the download is
138 still running when this command finishes, the download is stopped. For
139 more information, see Advertising manifests.
140 Arguments
142 • PROJECT|SOLUTION
143 The project or solution to publish.
145 • PROJECT is the path and filename of a C#, F#, or Visual Basic
147 project file, or the path to a directory that contains a C#, F#, or
148 Visual Basic project file. If the directory is not specified, it
149 defaults to the current directory.
150 • SOLUTION is the path and filename of a solution file (.sln exten‐
152 sion), or the path to a directory that contains a solution file.
153 If the directory is not specified, it defaults to the current di‐
154 rectory. Available since .NET Core 3.0 SDK.
155
157 • -a|--arch <ARCHITECTURE>
158 Specifies the target architecture. This is a shorthand syntax for
160 setting the Runtime Identifier (RID), where the provided value is
161 combined with the default RID. For example, on a win-x64 machine,
162 specifying --arch x86 sets the RID to win-x86. If you use this op‐
163 tion, don’t use the -r|--runtime option. Available since .NET 6 Pre‐
164 view 7.
165 • -c|--configuration <CONFIGURATION>
167 Defines the build configuration. The default for most projects is
169 Debug, but you can override the build configuration settings in your
170 project.
171 • -f|--framework <FRAMEWORK>
173 Publishes the application for the specified target framework. You
175 must specify the target framework in the project file.
176 • --force
178 Forces all dependencies to be resolved even if the last restore was
180 successful. Specifying this flag is the same as deleting the
181 project.assets.json file.
182 • -?|-h|--help
184 Prints out a description of how to use the command.
186 • --interactive
188 Allows the command to stop and wait for user input or action. For
190 example, to complete authentication. Available since .NET Core 3.0
191 SDK.
192 • --manifest <PATH_TO_MANIFEST_FILE>
194 Specifies one or several target manifests to use to trim the set of
196 packages published with the app. The manifest file is part of the
197 output of the dotnet store command. To specify multiple manifests,
198 add a --manifest option for each manifest.
199 • --no-build
201 Doesn’t build the project before publishing. It also implicitly sets
203 the --no-restore flag.
204 • --no-dependencies
206 Ignores project-to-project references and only restores the root
208 project.
209 • --nologo
211 Doesn’t display the startup banner or the copyright message. Avail‐
213 able since .NET Core 3.0 SDK.
214 • --no-restore
216 Doesn’t execute an implicit restore when running the command.
218 • -o|--output <OUTPUT_DIRECTORY>
220 Specifies the path for the output directory.
222 If not specified, it defaults to [project_file_folder]/bin/[configu‐
224 ration]/[framework]/publish/ for a framework-dependent executable and
225 cross-platform binaries. It defaults to [project_file_fold‐
226 er]/bin/[configuration]/[framework]/[runtime]/publish/ for a self-
227 contained executable.
228 In a web project, if the output folder is in the project folder, suc‐
230 cessive dotnet publish commands result in nested output folders. For
231 example, if the project folder is myproject, and the publish output
232 folder is myproject/publish, and you run dotnet publish twice, the
233 second run puts content files such as .config and .json files in
234 myproject/publish/publish. To avoid nesting publish folders, specify
235 a publish folder that is not directly under the project folder, or
236 exclude the publish folder from the project. To exclude a publish
237 folder named publishoutput, add the following element to a Property‐
238 Group element in the .csproj file:
239 <DefaultItemExcludes>$(DefaultItemExcludes);publishoutput**</DefaultItemExcludes>
241 • .NET Core 3.x SDK and later
243 If you specify a relative path when publishing a project, the gen‐
245 erated output directory is relative to the current working directo‐
246 ry, not to the project file location.
247 If you specify a relative path when publishing a solution, all out‐
249 put for all projects goes into the specified folder relative to the
250 current working directory. To make publish output go to separate
251 folders for each project, specify a relative path by using the ms‐
252 build PublishDir property instead of the --output option. For ex‐
253 ample, dotnet publish -p:PublishDir=.\publish sends publish output
254 for each project to a publish folder under the folder that contains
255 the project file.
256 • .NET Core 2.x SDK
258 If you specify a relative path when publishing a project, the gen‐
260 erated output directory is relative to the project file location,
261 not to the current working directory.
262 If you specify a relative path when publishing a solution, each
264 project’s output goes into a separate folder relative to the
265 project file location. If you specify an absolute path when pub‐
266 lishing a solution, all publish output for all projects goes into
267 the specified folder.
268 • --os <OS>
270 Specifies the target operating system (OS). This is a shorthand syn‐
272 tax for setting the Runtime Identifier (RID), where the provided val‐
273 ue is combined with the default RID. For example, on a win-x64 ma‐
274 chine, specifying --os os sets the RID to os-x64. If you use this
275 option, don’t use the -r|--runtime option. Available since .NET 6
276 Preview 7.
277 • --self-contained [true|false]
279 Publishes the .NET runtime with your application so the runtime
281 doesn’t need to be installed on the target machine. Default is true
282 if a runtime identifier is specified and the project is an executable
283 project (not a library project). For more information, see .NET ap‐
284 plication publishing and Publish .NET apps with the .NET CLI.
285 If this option is used without specifying true or false, the default
287 is true. In that case, don’t put the solution or project argument
288 immediately after --self-contained, because true or false is expected
289 in that position.
290 • --no-self-contained
292 Equivalent to --self-contained false. Available since .NET Core 3.0
294 SDK.
295 • -r|--runtime <RUNTIME_IDENTIFIER>
297 Publishes the application for a given runtime. For a list of Runtime
299 Identifiers (RIDs), see the RID catalog. For more information, see
300 .NET application publishing and Publish .NET apps with the .NET CLI.
301 If you use this option, use --self-contained or --no-self-contained
302 also.
303 • -v|--verbosity <LEVEL>
305 Sets the verbosity level of the command. Allowed values are q[uiet],
307 m[inimal], n[ormal], d[etailed], and diag[nostic]. The default is
308 minimal. For more information, see <xref:Microsoft.Build.Frame‐
309 work.LoggerVerbosity>.
310 • --version-suffix <VERSION_SUFFIX>
312 Defines the version suffix to replace the asterisk (*) in the version
314 field of the project file.
315
317 • Create a framework-dependent cross-platform binary for the project in
318 the current directory:
319 dotnet publish
321 Starting with .NET Core 3.0 SDK, this example also creates a frame‐
323 work-dependent executable for the current platform.
324 • Create a self-contained executable for the project in the current di‐
326 rectory, for a specific runtime:
327 dotnet publish --runtime osx.10.11-x64
329 The RID must be in the project file.
331 • Create a framework-dependent executable for the project in the cur‐
333 rent directory, for a specific platform:
334 dotnet publish --runtime osx.10.11-x64 --self-contained false
336 The RID must be in the project file. This example applies to .NET
338 Core 3.0 SDK and later versions.
339 • Publish the project in the current directory, for a specific runtime
341 and target framework:
342 dotnet publish --framework netcoreapp3.1 --runtime osx.10.11-x64
344 • Publish the specified project file:
346 dotnet publish ~/projects/app1/app1.csproj
348 • Publish the current application but don’t restore project-to-project
350 (P2P) references, just the root project during the restore operation:
351 dotnet publish --no-dependencies
353 See also
355 • .NET application publishing overview
356 • Publish .NET apps with the .NET CLI
358 • Target frameworks
360 • Runtime Identifier (RID) catalog
362 • Working with macOS Catalina Notarization
364 • Directory structure of a published application
366 • MSBuild command-line reference
368 • Visual Studio publish profiles (.pubxml) for ASP.NET Core app deploy‐
370 ment
371 • dotnet msbuild
373 • ILLInk.Tasks
375 (1)