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
Copy file name to clipboardExpand all lines: documentation/general/dotnet-run-file.md
+15-9Lines changed: 15 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -47,7 +47,8 @@ The command takes a path which can be either
47
47
## Target path
48
48
49
49
The path passed to `dotnet run ./some/path.cs` is called *the target path*.
50
-
The target path must be a file which has the `.cs` file extension.
50
+
The target path must be a file which either has the `.cs` file extension,
51
+
or a file whose contents start with `#!`.
51
52
*The target directory* is the directory of the target file.
52
53
53
54
## Integration into the existing `dotnet run` command
@@ -57,7 +58,7 @@ specifically `file.cs` is passed as the first command-line argument to the targe
57
58
We preserve this behavior to avoid a breaking change.
58
59
The file-based build and run kicks in only when:
59
60
- a project file cannot be found (in the current directory or via the `--project` option), and
60
-
- if the target file exists and has the `.cs` file extension.
61
+
- if the target file exists, and has the `.cs` file extension or contents that start with `#!`.
61
62
62
63
File-based programs are processed by `dotnet run` equivalently to project-based programs unless specified otherwise in this document.
63
64
For example, the remaining command-line arguments after the first argument (the target path) are passed through to the target app
@@ -71,11 +72,11 @@ We want to report an error for non-entry-point files to avoid the confusion of b
71
72
72
73
Internally, the SDK CLI detects entry points by parsing all `.cs` files in the directory tree of the entry point file with default parsing options (in particular, no `<DefineConstants>`)
73
74
and checking which ones contain top-level statements (`Main` methods are not supported for now as that would require full semantic analysis, not just parsing).
74
-
Results of this detection are used to exclude other entry points from [builds](#multiple-entry-points) and [app directive collection](#directives-for-project-metadata).
75
+
Results of this detection are used to exclude other entry points from [builds](#multiple-entry-points) and [file-level directive collection](#directives-for-project-metadata).
75
76
This means the CLI might consider a file to be an entry point which later the compiler doesn't
76
77
(for example because its top-level statements are under `#if !SYMBOL` and the build has `DefineConstants=SYMBOL`).
77
78
However such inconsistencies should be rare and hence that is a better trade off than letting the compiler decide which files are entry points
78
-
because that could require multiple builds (first determine entry points and then re-build with app directives except those from other entry points).
79
+
because that could require multiple builds (first determine entry points and then re-build with file-level directives except those from other entry points).
79
80
To avoid parsing all C# files twice (in CLI and in the compiler), the CLI could use the compiler server for parsing so the trees are reused
80
81
(unless the parse options change via the directives), and also [cache](#optimizations) the results to avoid parsing on subsequent runs.
81
82
@@ -86,6 +87,10 @@ other files in the target directory or its subdirectories are included in the co
86
87
For example, other `.cs` files but also `.resx` (embedded resources).
87
88
Similarly, implicit build files like `Directory.Build.props` or `Directory.Packages.props` are used during the build.
88
89
90
+
> [!CAUTION]
91
+
> Multi-file support is postponed for .NET 11.
92
+
> In .NET 10, only the single file passed as the command-line argument to `dotnet run` is part of the compilation.
93
+
89
94
### Nested files
90
95
91
96
If there are nested project files like
@@ -146,21 +151,22 @@ They are not cleaned immediately because they can be re-used on subsequent runs
146
151
147
152
## Directives for project metadata
148
153
149
-
It is possible to specify some project metadata via *app directives*
154
+
It is possible to specify some project metadata via *file-level directives*
150
155
which are [ignored][ignored-directives] by the C# language but recognized by the SDK CLI.
151
156
Directives `sdk`, `package`, and `property` are translated into `<Project Sdk="...">`, `<PackageReference>`, and `<Property>` project elements, respectively.
152
157
Other directives result in an error, reserving them for future use.
The value must be separated from the name of the directive by white space (`@` is additionally allowed separator for the package directive)
166
+
The value must be separated from the kind (`package`/`sdk`/`property`) of the directive by whitespace
162
167
and any leading and trailing white space is not considered part of the value.
163
-
Any value can optionally have two parts separated by a space (more whitespace characters could be allowed in the future).
168
+
Any value can optionally have two parts separated by `@` in case of `package`/`sdk` or `=` in case of `property`
169
+
and whitespace is trimmed from the two parts around the separator.
164
170
The value of the first `#:sdk` is injected into `<Project Sdk="{0}">` with the separator (if any) replaced with `/`,
165
171
and the subsequent `#:sdk` directive values are split by the separator and injected as `<Sdk Name="{0}" Version="{1}" />` elements (or without the `Version` attribute if there is no separator).
166
172
It is an error if the first part (name) is empty (the version is allowed to be empty, but that results in empty `Version=""`).
0 commit comments