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.
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.
The `GivenFailedPackageInstallWhenRunWithPackageIdItShouldFail` test should
match against `ToolInstallationFailedWithRestoreGuidance` and not
`ToolInstallationFailed`. This passed prior to the LOC update because
the former started with the latter and a "contains" match was being performed.
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.
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.
Test build was causing restore and build in same evaluation, which was
always incorrect, but with a recent change to sdk, it will always fail
outright instead of sometimes getting lucky enough for it not to matter.
This was therefore a breaking change and we will discuss separately how
to handle it. This takes the bad pattern out of the test build to unblock
the build.
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.
Give a different error to guide use to install via global tools so, if several bundled DotnetTools cannot finish source build on time. The user can use global tools to get it.
The original plan that adding a different resolver is hard due to resolver can only find dll that will be used to spawn a process. However, the command constructor will give an error message when resolver find null. By adding a different error when the command name is part of the list, it can achieve the same goal.
If there are shims packaged by convention in nupkg. Shim Repository will simply copy it to the right location.
The query interface ToolPackageInstance will be in charge of finding the shim folder and filter the right RID. Shim Repository will pick the right file after the folder is located since Shim Repository knows the shim name and it also book keep the files at uninstallation.
During development, due to the wrong adapter level. The mock duplicated too much logic. So, I corrected the abstraction level to lower (only create shim). And replaced the existing mock with a much smaller one without any atomic control and file move, copy logic. At the same time. The chmod, which is a IO action, causes problem during tests. So I added adapter layer to it and put it in Util.
* release/2.1.1xx:
Fixing another typo in that is breaking RHEL.
Fix a typo in the rpm.targets when testing the rpm generated packages.
Update to aspnet 2.0.7 build 230
Producing an empty commit to trigger a rebuild of the CLI
Fix AspNetCoreRuntimeBuildDropFeed to use CoreSetupBlobRootUrl
Adding a work around for publishing self-contained apps to RIDs that are not available for Microsoft.NETCore.App 2.0.0.
Reverse the order in which old runtime stores are listed
Update to ASP.NET Core 2.0.7 build 228
Moving the opensuse 43.2 docker file to the right folder.
Updating the CLI branding to 2.1.105, to go over the 104 release we will have to do for NuGet. Also, fixed the branding of the runtime in our installers to 2.0.7.
Updating the runtime to 2.0.7 and the CLI branding to 2.1.104.
Update SDK to 2.1.100-preview-62730-07
Add msbuild myget.org feed
MSBuild 15.6.84
Conflicts:
build/Branding.props
build/DependencyVersions.props
build/NugetConfigFile.targets
build/Version.props
packaging/osx/clisdk/resources/cs.lproj/conclusion.html
packaging/osx/clisdk/resources/de.lproj/conclusion.html
packaging/osx/clisdk/resources/en.lproj/conclusion.html
packaging/osx/clisdk/resources/es.lproj/conclusion.html
packaging/osx/clisdk/resources/fr.lproj/conclusion.html
packaging/osx/clisdk/resources/it.lproj/conclusion.html
packaging/osx/clisdk/resources/ja.lproj/conclusion.html
packaging/osx/clisdk/resources/ko.lproj/conclusion.html
packaging/osx/clisdk/resources/pl.lproj/conclusion.html
packaging/osx/clisdk/resources/pt-br.lproj/conclusion.html
packaging/osx/clisdk/resources/ru.lproj/conclusion.html
packaging/osx/clisdk/resources/tr.lproj/conclusion.html
packaging/osx/clisdk/resources/zh-hans.lproj/conclusion.html
packaging/osx/clisdk/resources/zh-hant.lproj/conclusion.html
packaging/windows/clisdk/bundle.wxl
On environments where registry access is disabled, the first run experience
fails because it could not add the tools path to the user's environment.
This fix properly handles the security exception by printing a warning and
continuing. Users will have to manually add the PATH environment variable to
their environments to prevent `dotnet tool install` from printing PATH
instructions.
A new file sentinel is added to track whether or not the PATH has been
modified. The first run experience also now correctly skips modifying the PATH
if `DOTNET_SKIP_FIRST_TIME_EXPERIENCE` is set.
Fixes#8874.
This commit checks that the `--tool-path` option for the `tool list` and `tool
uninstall` commands is a directory that exists.
If the directory does not exist, an error and the command help is displayed.
Fixes#8931.
* Publish app host to folder under SDK
* Use carried apphost as shim
* Remove full framework launcher
* Fix test run command issue
* Use latest release/2.1 build
* Test with 32 bit env
* Add missing return
* Update to latest prodcon build
* Add xlfs
