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
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -71,11 +71,11 @@ We want to report an error for non-entry-point files to avoid the confusion of b
71
71
72
72
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
73
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).
74
+
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
75
This means the CLI might consider a file to be an entry point which later the compiler doesn't
76
76
(for example because its top-level statements are under `#if !SYMBOL` and the build has `DefineConstants=SYMBOL`).
77
77
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).
78
+
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
79
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
80
(unless the parse options change via the directives), and also [cache](#optimizations) the results to avoid parsing on subsequent runs.
81
81
@@ -146,7 +146,7 @@ They are not cleaned immediately because they can be re-used on subsequent runs
146
146
147
147
## Directives for project metadata
148
148
149
-
It is possible to specify some project metadata via *app directives*
149
+
It is possible to specify some project metadata via *file-level directives*
150
150
which are [ignored][ignored-directives] by the C# language but recognized by the SDK CLI.
151
151
Directives `sdk`, `package`, and `property` are translated into `<Project Sdk="...">`, `<PackageReference>`, and `<Property>` project elements, respectively.
152
152
Other directives result in an error, reserving them for future use.
Snapshot-based testing is a technique used in the .NET SDK to ensure that the command-line interface (CLI) behaves as expected. This document provides an overview of how snapshot-based testing works, particularly for CLI completions, and how to manage and update snapshots.
4
+
5
+
## CLI Completions Snapshot Testing
6
+
7
+
The point of the tests is to keep an eye on the CLI, since it is our user interface. When the CLI changes in a way that impacts completions (new commands, options, defaults) we need to inspect and reconcile the baselines. Most of this happens in the [dotnet.Tests][dotnet.Tests] project, in the [Microsoft.DotNet.Cli.Completions.Tests.DotnetCliSnapshotTests][snapshot-tests] tests.
8
+
9
+
These tests use [Verify][Verify] to perform snapshot testing - storing the results of a known good 'baseline' as a snapshot and comparing the output of the same action performed with changes in your PR. Verify calls these baselines 'verified' files. When the test computes a new snapshot for comparison, this is called a 'received' file. Verify compares the 'verified' file to the 'received' file for each test, and if they are not the same provides a git-diff in the console output for the test.
10
+
11
+
To fix these tests, you need to diff the two files and visually inspect the changes. If the changes to the 'received' file are what you want to see (new commands, new options, renames, etc) then you rename the 'received' file to 'verified' and commit that change to the 'verified' file. There are two MSBuild Targets on the dotnet.Tests project that you can use to help you do this, both of which are intended to be run after you run the snapshot tests locally:
12
+
13
+
*[CompareCliSnapshots][compare] - this Target copies the .received. files from the artifacts directory, where they are created due to the way we run tests, to the [snapshots][snapshots] directory in the dotnet.Tests project. This makes it much easier to diff the two.
14
+
*[UpdateCliSnapshots][update] - this Target renames the .received. files to .verified. in the local [snapshots][snapshots] directory, and so acts as a giant 'I accept these changes' button. Only use this if you've diffed the snapshots and are sure they match your expectations.
Copy file name to clipboardExpand all lines: src/Cli/dotnet/Commands/CliCommandStrings.resx
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -1513,6 +1513,10 @@ Tool '{1}' (version '{2}') was successfully installed. Entry is added to the man
1513
1513
<value>Some directives cannot be converted: the first error is at {0}. Run the file to see all compilation errors. Specify '--force' to convert anyway.</value>
1514
1514
<comment>{Locked="--force"}. {0} is the file path and line number.</comment>
<value>If you intended to install a global tool, add `--global` to the command.
1980
-
If you would like to create a manifest, use the `--create-manifest-if-needed` flag with the `dotnet tool install` command, or use `dotnet new tool-manifest`, usually in the repo root directory.</value>
0 commit comments