This appears to be a difference between the 2.2.0-preview SDK currently
being used in core-sdk and the 2.1.401-preview SDK currently being used
in source-build. In the 2.2.0 SDK, this target happens to run before
the resolved package list is used, but in the 2.1.401 it is not, so I
added the explicit dependency (doesn't affect anything in the 2.2.0 SDK).
* 'master' of /Users/livarcocc/Documents/git/cli: (1063 commits)
Updating signing project to use new intermediate directory (int).
Update runtimeconfig.json doc for 2.1 (#9382)
Shortening the path to the intermediate folder by renaming it to int.
fix typo (#9364)
Updating asp.net to 2.2.0 as well.
Updating the build and tests to work with the 2.2.0 runtime.
Simplified combining dictionaries in Telemetry
Fixing 'Channel' and 'BranchName': "release/2.1.4xx" to "master" (#9362)
Fix extraction of folders (#9335)
Update Sha256Hasher.cs
Fix relative path tool path (#9330)
Insert updated SDK from 2.1.4xx branch
MSBuild 15.8.60
Fix crash when user home directory cannot be determined.
Make `CliFolderPathCalculator` a static class.
Don't add the ReleaseSuffix to the branding on the CLI when DropSuffix is set to true.
Add retry when Directory.Move (#9313)
Override new SdkResult public properties
Add reference to Microsoft.Build.NuGetSdkResolver
Disable crossgen for MSBuild inline-task refs
...
Currently, dotnet will crash with an `ArgumentNullException` if `USERPROFILE`
(Windows) or `HOME` (macOS and Linux) is not set in the environment. This
is because there is a missing null check after retrieving the environment
variable's value. Additionally, if either variable is set to an empty string,
a `.dotnet` directory is created in the current directory where dotnet is being
run.
This commit fixes this by printing a graceful error informing the user the home
directory could not be determined and to set `DOTNET_CLI_HOME` to the directory
to use. This variable will be respected before `USERPROFILE` or `HOME`. It is
likely that CI environments where `HOME` is not set can use `DOTNET_CLI_HOME`
to specify a local temporary location; by using this variable rather than
setting `HOME`, it is guaranteed to only affect dotnet.
It was discussed that we should perhaps fallback to some temporary location if
the home directory could not be determined, but NuGet currently requires `HOME`
to be set to work. Because of this, it was decided that we should just handle
this case gracefully and provide a way for users to override the home directory
without relying on `USERPROFILE`/`HOME` entirely.
Closes#8053.
This commit attempts to make the command line help user experience for `dotnet`
more consistent for all of the built-in SDK commands.
The following has been changed:
* Organized the top-level help into a section detailing how to run .NET
applications and a section on running SDK commands.
* Sorted the SDK commands by name (previous ordering was undefined).
* Removed `--verbosity` from the "common options section" since it is not a
top-level option, nor is it common to all commands.
* Added missing parameter names for parameterized options (especially for the
`dotnet tool` subcommands).
* Fixed the localization of parameter names for parameterized options.
* Added missing `PROJECT` parameter to a few commands.
* Fixed the localization of the build command's `PROJECT` parameter description.
* Fixed the confusing descriptions for the `--framework`, `--configuration`,
and `--runtime` options that were being shared between different commands.
* Fixed the "unknown command" error for `dotnet help <command>` to show in red.
* Deleted .resx for `dotnet msbuild` that is no longer used.
* Change the option descriptions to be more consistent in their grammatical
structure.
* Removed extra blank line from end of help output.
Fixes#7431.
Fixes#9230.
Fixes#9165.
This commit adds a few simple unit tests to cover the `dotnet complete`
command.
It only checks the top-level output, integration with the `new`
command from the templating engine, and the custom `nuget` command parser that
is solely intended for use with `dotnet complete`.
This commit removes `internal-reportinstallsuccess` from `dotnet complete` by
changing the command's help text to an empty string. This causes the parser to
treat the command as hidden and does not match the command name for
suggestions.
Fixes#9111.
This commit improves command completion by updating the `new` and `nuget` parsers to
match their current supported syntax. Removes the unnecessary description
strings that were not used (these commands are parsed by assemblies external to
the CLI). The top level options are also sync'd to the currently supported
options.
Additionally, it unhides the `msbuild` and `vstest` commands so that `dotnet
complete` suggests them.
Fixes#9286.
The `dotnet sln list` command uses `Project reference(s)` as the header for the
output instead of `Project(s)`. To be consistent with Visual Studio, the header
should refer to these as projects rather than project references as users can't
add "project references" to a solution.
This commit changes the header to `Project(s)`.
Additionally, the command now filters out solution folders and only shows
projects.
Fixes#9246.
Commit 10289504a8 changed the default verbosity
option used for MSBuild from `-v:quiet` to `-verbosity:quiet`. This triggered a
match that was being done against arguments starting with `-verbosity` to
forward the value to VSTest via the `VSTestVerbosity` property. The result is
that VSTest is using a default verbosity of `quiet`, suppressing error output
that users expect to see.
The fix is to change the check to only match against user-supplied options.
The default level the command uses for MSBuild is not forwarded to VSTest.
Fixes#9229.
do as part of first run based on whether this is the invoke-reportsuccess from a native installer or a regular command
being invoked for the first time. This in turn allows us to ignore the skip first run variable on native installers and
expand the cache always in those cases.
This commit fixes adding the tools directory to the user's PATH for the native
installers.
The issue was a regression caused by #8886. The change used a "no-op" sentinel
file that reported it existed. This "no-op" sentinel was used for the native
installers. Unlike the other "no-op" sentinels used by the native installer,
we do want PATH to be modified by the native installer.
The fix is to change the "no-op" sentinel to report the file doesn't exist, but
also to not to attempt to create the file.
This fixes#9208.
On Windows, the Razor server correctly creates the pid file with
`FileAccess.Write` and `FileOptions.DeleteOnClose`. This requires a share mode
of `FileShare.Write | FileShare.Delete` to open. However, the
`dotnet build-server shutdown` command was opening the file with
`FileShare.Read`. As a result, an `IOException` was being thrown and was not
handled.
This change first opens the file with the appropriate share access and also
properly handles a failure to access or read the contents of the pid file.
Additionally, an integration test was added to test that Razor server shutdown
works as expected.
Fixes#9158.
This commit ensures that any `/property` option's value is surrounded by quotes
to allow MSBuild to properly interpret special characters like semicolons.
Users familiar with MSBuild expect `/property:Name="Value"` to handle
semicolons. However, since `dotnet` parses the command line first, the
quotes get processed by its command line parser. This results in
`/property:Name=Value` being passed to MSBuild, which will not parse a "Value"
containing a semicolon correctly.
Since it is safe to always quote the property value for this option, this fix
simply ensures that the value is surrounded by quotes.
This fixes the issue for all commands that forward arguments to MSBuild.
Fixes#7791.
Commit 9cc2b7cd2f regressed the `--source-feed`
option so that it no longer accepted relative paths. Because the option is now
saved to the temp project file, any relative paths specified by the
`--source-feed` option were made relative to the temp project path and not from
the current working directory of where dotnet was run.
The fix is to use `Path.GetFullPath` of the `--source-feed` option, provided
the option specified was not an absolute URI.
Fixes#9132.
Should use MsBuildProjectExtensionsPath instead.
Change the property passin by project file instead of command line. It is more reliable passing path in xml and also the timing of MsBuildProjectExtensionsPath is controlled. (Before loading SDK)
Change mock fake project to use “;” instead, since c:\path contains “:”.
Previously, Razor server discovery for the `build-server shutdown` command was
implemented by invoking MSBuild on a project file in the current directory to
evaluate the path to the Razor server dll. This was problematic since it would
only discover a single running Razor server instance and required that the user
run the `build-server shutdown` command from a specific location.
Razor's server now writes a "pid file" to a well-known location
(`~/.dotnet/pids/build`) which the command can now enumerate to discover, and
shutdown, the running Razor servers.
This commit changes the Razor server discovery to use the pid files and removes
the requirement that users need to run the command in specific directories to
work.
Fixes#9084.
