You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update file-based app functionality in command reference (#48738)
* add file based changes for dotnet build
* add file based command for dotnet clean
* add file-based app options for dotnet-run
* add file-based app details for dotnet publish
* add file-based app info for dotnet-restore
* Fix indentation
* add in file command
* make consistency edits across commands
* Specify the version file-based programs are available in.
* apply changes from review feedback
* move project-solution-file arguments to an include file
* add trailing newline to include
* specify behavior of dotnet run for arguments and using file option
* Add trailing newline at end of file
The `dotnet build` command builds the projectand its dependencies into a set of binaries. The binaries include the project's code in Intermediate Language (IL) files with a *.dll* extension. Depending on the project type and settings, other files may be included, such as:
35
+
The `dotnet build` command builds the project, solution, or file-based app and its dependencies into a set of binaries. The binaries include the project's code in Intermediate Language (IL) files with a *.dll* extension. Depending on the project type and settings, other files may be included, such as:
36
36
37
-
- An executable that can be used to run the application, if the project type is an executable targeting .NET Core 3.0 or later.
37
+
- An executable that can be used to run the application.
38
38
- Symbol files used for debugging with a *.pdb* extension.
39
39
- A *.deps.json* file, which lists the dependencies of the application or library.
40
40
- A *.runtimeconfig.json* file, which specifies the shared runtime and its version for an application.
41
41
- Other libraries that the project depends on (via project references or NuGet package references).
42
42
43
-
For executable projects targeting versions earlier than .NET Core 3.0, library dependencies from NuGet are typically NOT copied to the output folder. They're resolved from the NuGet global packages folder at run time. With that in mind, the product of `dotnet build` isn't ready to be transferred to another machine to run. To create a version of the application that can be deployed, you need to publish it (for example, with the [dotnet publish](dotnet-publish.md) command). For more information, see [.NET Application Deployment](../deploying/index.md).
44
-
45
43
For executable projects targeting .NET Core 3.0 and later, library dependencies are copied to the output folder. This means that if there isn't any other publish-specific logic (such as Web projects have), the build output should be deployable.
46
44
47
45
### Implicit restore
@@ -64,7 +62,7 @@ To produce a library, omit the `<OutputType>` property or change its value to `L
64
62
65
63
### MSBuild
66
64
67
-
`dotnet build` uses MSBuild to build the project, so it supports both parallel and incremental builds. For more information, see [Incremental Builds](/visualstudio/msbuild/incremental-builds).
65
+
`dotnet build` uses MSBuild to build the project, solution, or file-based app. It supports both parallel and incremental builds. For more information, see [Incremental Builds](/visualstudio/msbuild/incremental-builds).
68
66
69
67
In addition to its options, the `dotnet build` command accepts MSBuild options, such as `-p` for setting properties or `-l` to define a logger. For more information about these options, see the [MSBuild Command-Line Reference](/visualstudio/msbuild/msbuild-command-line-reference). Or you can also use the [dotnet msbuild](dotnet-msbuild.md) command.
70
68
@@ -77,9 +75,7 @@ Running `dotnet build` is equivalent to running `dotnet msbuild -restore`; howev
77
75
78
76
## Arguments
79
77
80
-
`PROJECT | SOLUTION`
81
-
82
-
The project or solution file to build. If a project or solution file isn't specified, MSBuild searches the current working directory for a file that has a file extension that ends in either *proj* or *sln* and uses that file.
@@ -30,37 +30,35 @@ The `dotnet clean` command cleans the output of the previous build. It's impleme
30
30
31
31
## Arguments
32
32
33
-
`PROJECT | SOLUTION`
34
-
35
-
The MSBuild project or solution to clean. If a project or solution file is not specified, MSBuild searches the current working directory for a file that has a file extension that ends in *proj* or *sln*, and uses that file.
The [framework](../../standard/frameworks.md) that was specified at build time. The framework must be defined in the [project file](../project-sdk/overview.md). If you specified the framework at build time, you must specify the framework when cleaning.
Doesn't display the startup banner or the copyright message.
54
52
55
-
***`-o|--output <OUTPUT_DIRECTORY>`**
53
+
-**`-o|--output <OUTPUT_DIRECTORY>`**
56
54
57
55
The directory that contains the build artifacts to clean. Specify the `-f|--framework <FRAMEWORK>` switch with the output directory switch if you specified the framework when the project was built.
58
56
59
57
- .NET 7.0.200 SDK and later
60
58
61
59
If you specify the `--output` option when running this command on a solution, the CLI will emit a warning (an error in 7.0.200) due to the unclear semantics of the output path. The `--output` option is disallowed because all outputs of all built projects would be copied into the specified directory, which isn't compatible with multi-targeted projects, as well as projects that have different versions of direct and transitive dependencies. For more information, see [Solution-level `--output` option no longer valid for build-related commands](../compatibility/sdk/7.0/solution-level-output-no-longer-valid.md).
62
60
63
-
***`-r|--runtime <RUNTIME_IDENTIFIER>`**
61
+
-**`-r|--runtime <RUNTIME_IDENTIFIER>`**
64
62
65
63
Cleans the output folder of the specified runtime. This is used when a [self-contained deployment](../deploying/index.md#self-contained-deployment) was created.
66
64
@@ -70,13 +68,21 @@ The MSBuild project or solution to clean. If a project or solution file is not s
70
68
71
69
## Examples
72
70
73
-
* Clean a default build of the project:
71
+
- Clean a default build of the project:
74
72
75
73
```dotnetcli
76
74
dotnet clean
77
75
```
78
76
79
-
* Clean a project built using the Release configuration:
77
+
- Clean a file-based program:
78
+
79
+
```dotnetcli
80
+
dotnet clean Program.cs.
81
+
```
82
+
83
+
File-based app support was added in .NET SDK 10.0.100.
84
+
85
+
- Clean a project built using the Release configuration:
@@ -114,13 +114,7 @@ For more information, see the following resources:
114
114
115
115
## Arguments
116
116
117
-
-**`PROJECT|SOLUTION`**
118
-
119
-
The project or solution to publish.
120
-
121
-
*`PROJECT` is the path and filename of a C#, F#, or Visual Basic project file, or the path to a directory that contains a C#, F#, or Visual Basic project file. If the directory is not specified, it defaults to the current directory.
122
-
123
-
*`SOLUTION` is the path and filename of a solution file (*.sln* or *.slnx* extension), or the path to a directory that contains a solution file. If the directory is not specified, it defaults to the current directory.
@@ -186,12 +180,6 @@ For more information, see the following resources:
186
180
187
181
If you specify a relative path when publishing a solution, all output for all projects goes into the specified folder relative to the current working directory. To make publish output go to separate folders for each project, specify a relative path by using the msbuild `PublishDir` property instead of the `--output` option. For example, `dotnet publish -p:PublishDir=.\publish` sends publish output for each project to a `publish` folder under the folder that contains the project file.
188
182
189
-
- .NET Core 2.x SDK
190
-
191
-
If you specify a relative path when publishing a project, the generated output directory is relative to the project file location, not to the current working directory.
192
-
193
-
If you specify a relative path when publishing a solution, each project's output goes into a separate folder relative to the project file location. If you specify an absolute path when publishing a solution, all publish output for all projects goes into the specified folder.
194
-
195
183
[!INCLUDE [os](../../../includes/cli-os.md)]
196
184
197
185
-**`--sc|--self-contained [true|false]`**
@@ -268,6 +256,14 @@ For more information, see the following resources:
268
256
dotnet publish --no-dependencies
269
257
```
270
258
259
+
- Publish the file-based C# program *app.cs* in the current directory:
260
+
261
+
```dotnetcli
262
+
dotnet publish app.cs
263
+
```
264
+
265
+
File-based program support was added in .NET SDK 10.0.100.
Arguments passed to the application that is being run.
61
+
62
+
Any arguments that aren't recognized by `dotnet run` are passed to the application. To separate arguments for `dotnet run` from arguments for the application, use the `--` option.
63
+
56
64
## Options
57
65
58
66
-**`--`**
@@ -75,6 +83,24 @@ To run the application, the `dotnet run` command resolves the dependencies of th
75
83
76
84
Builds and runs the app using the specified [framework](../../standard/frameworks.md). The framework must be specified in the project file.
77
85
86
+
-**`--file <FILE_PATH>`**
87
+
88
+
The path to the file-based app to run. If a path isn't specified, the current directory is used to find and run the file. For more information on file-based apps, see [Build file-based C# apps](/dotnet/csharp/fundamentals/tutorials/file-based-programs).
89
+
90
+
On Unix, you can run file-based apps directly, using the source file name on the command line instead of `dotnet run`. First, ensure the file has execute permissions. Then, add a shebang line `#!` as the first line of the file, for example:
91
+
92
+
```csharp
93
+
#!/usr/bin/env dotnet run
94
+
```
95
+
96
+
Then you can run the file directly from the command line:
97
+
98
+
```bash
99
+
./ConsoleApp.cs
100
+
```
101
+
102
+
Introduced in .NET SDK 10.0.100.
103
+
78
104
-**`--force`**
79
105
80
106
Forces all dependencies to be resolved even if the last restore was successful. Specifying this flag is the same as deleting the *project.assets.json* file.
@@ -155,6 +181,14 @@ The environment is constructed in the same order as this list, so the `-e|--envi
155
181
dotnet run
156
182
```
157
183
184
+
- Run the specified file-based app in the current directory:
185
+
186
+
```dotnetcli
187
+
dotnet run --file ConsoleApp.cs
188
+
```
189
+
190
+
File-based app support was added in .NET SDK 10.0.100.
191
+
158
192
- Run the specified project:
159
193
160
194
```dotnetcli
@@ -178,3 +212,16 @@ The environment is constructed in the same order as this list, so the `-e|--envi
178
212
```dotnetcli
179
213
dotnet run --verbosity m
180
214
```
215
+
216
+
- Run the project in the current directory using the specified framework and pass arguments to the application:
217
+
218
+
```dotnetcli
219
+
dotnet run -f net6.0 -- arg1 arg2
220
+
```
221
+
222
+
In the following example, three arguments are passed to the application. One argument is passed using `-`, and two arguments are passed after `--`:
0 commit comments