This commit implements the requested changes from the PR code review.
- Remove unnecessary comments
- Use Directory.Exists rather than getting file attributes
- Use GracefulException where appripriate
- Improve test names and fix spacing
- Don't force trailing slash on directory
- Don't use option forwarding
- Delete unnecessary MSBuild.exe[.config] files from test project
- Use forwarded options
* dotnet/release/2.1.5xx:
MSBuild 15.9.8-preview
MSBuild SDK Resolver Improvements (#9547)
Remove fallback folder
Remove redundent call, ensure no apt list
Update links in the readme to release/2.1.5xx
MSBuild 15.9.0-preview-000006
Use prebuild image
Revert "Disabled MSBuildTreatWarningsAsErrors"
Disabled MSBuildTreatWarningsAsErrors
Add back: "PUBLISH_NUPKG_TO_BLOB_FEED" to manage the no-suffix builds in 2.1
Adding the 2.1.3 runtime blob feed as a feed for the CLI
Update CLI branding to 2.1.402
Updated test
TestPlatform 15.9.0-preview Insertion
Update CLI branding to 2.1.203.
Fix warnings-as-errors in Linux packaging
Don't let crossgen warnings become msbuild warnings-as-errors
Fix build warning and treat msbuild warnings as errors
Conflicts:
README.md
build/DependencyVersions.props
build/package/Installer.DEB.proj
1. When there's no global.json, use latest SDK that is compatible with msbuild, not latest SDK overall
2. Respect VS setting to allow / disallow resolving to preview SDKs
This commit fixes the `ItPublishesFrameworkDependentWithRid` test to ensure
the apphost is present in the published files.
It also runs the application from the apphost to ensure it executes
successfully.
Fixes#9843.
The most recent SDK for 2.2.1xx pinned netstandard.library to 2.0.3 due to
https://github.com/dotnet/sdk/issues/2410.
This commit changes the expected version to match.
This commit suppresses the output that is displayed by the `dotnet run` command
when launch settings are being used, unless the verbosity level is above
"quiet".
Fixes#9545.
This commit integrates a fix from the SDK repo that sets
`DefaultProjectTypeGuid` for VB and C# projects when the projects are
multitargeting. This property is used by `dotnet sln add` to determine the
project type guid to map in the solution file.
Adding additional tests that cover the multitargeting scenario for `dotnet sln
add`.
Fixes#9477.
This commit adds a `--runtime` option to the `dotnet test` command for
consistency with other commands.
The option does not have a short form of `-r`, however, because `dotnet test`
already uses the short form for another option (results directory).
Fixes#9583.
The mode switch tests are failing as they hit the 2.2.1xx branch
because we don't have a dotnet/sdk with the needed support for
it. Since the feature is reverted in release/2.1.4xx anyway, revert
the tests ahead of time to match release/2.1.4xx (modulo s/2.1/2.2/)
* release/2.1.4xx:
Add XSLT Transform for apphost (#9609)
Update date test according to MicrosoftNETSdkPackageVersion update
Update MicrosoftNETCoreAppPackageVersion
Update SDK to 2.1.400-preview-63110-09
Revert implementation of the --mode option for the publish command.
Updating the WebSdk from aspnet/websdk/2.1.4xx
Removing 'Locked-file' test; CLI:release/2.1.3xx (#9604)
Log a verbose message when DOTNET_CLI_HOME is being used.
* release/2.1.3xx-MSRC:
Updates asp.net versions to match prodcon
Change the implicit asp.net core version for FDD apps to be pinned as 2.1.1.
Update expected versions to 2.1.2
Disable NewProjectRestoresCorrectPackageVersion "console" test for now.
Update the version for 'microsoft.netcore.app' to "2.1.1*"
Pass "PB_AssetRootUrl" explictly on the MSBuild call; we are looking for Microsoft.NETCore.App "2.1.0" or "2.1.1*"
Merged PR 126122: Fix alpine file ownership issues with newer docker
Fix mismatch of dotnet-watch with package variable name
Set package versions for bundled aspnet tools separately from the metapackage version
Split the version of Microsoft.AspNetCore.DeveloperCertificates.XPlat into a separate variable
Fixup myget feed for aspnetcore
Upgrade to aspnetcore 2.1.1-rtm-30818 and react to file name change
Updated Version.props
This commit reverts the implementation of the `--mode` option for the `dotnet
publish` command. A bug in the apphost prevents this feature from working
properly in some cases and there currently is not a mechanism to service it
with this feature.
The team has decided to move this feature to 2.2.1xx for the .NET Core SDK.
Fixesdotnet/sdk#2380.
This commit logs a diagnostic message when the `DOTNET_CLI_HOME` variable is
used. This enables users to determine where first-run-experience and global
tool files are being written to.
Fixes#9510.
* '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
...
Instead of command line to avoid escaping problem.
It can support most of the character including surrogate char. It cannot
support semicolon. However, semicolon is not allow to be part of the
user name.
Port 2.1.4xx fix 0251f677ede571b61a47ca24f38df8e09038277d while keep
BaseIntermediateOutputPath instead of MsBuildProjectExtensionsPath to
minimize the change.
* Use correct nuget version normalized format
* Change test accordingly
This matches nuget behavior
if restore with `<PackageReference Include="global.tool.console.demo" Version="1.0.*" />` there is no warning
and if restore with `<PackageReference Include="global.tool.console.demo" Version="1.0.0" />` there is warning due to no exact 1.0.0 find
* Add Compute UseBundledNETCoreAppPackageVersionAsDefaultNetCorePatchVersion
* Add tests to catch DefaultNetCorePatchVersion moving
* Update LatestPatchVersionForNetCore2_0 to 2.0.9, it is in the process of shipping
* Update LatestPatchVersionForNetCore1_0 and LatestPatchVersionForNetCore1_1
* release/2.1.3xx:
Updating the CLI stage0 to 2.1.300 and fixing some build failures.
Update Microsoft.NETCore.App Package Version
Formatting...
Drop the LZMA archive for every build.
This commit implements a `mode` option that can control how an application is
published with the `dotnet publish` command.
There are three supported modes:
* self-contained: publishes a self-contained application (same as
--self-contained).
* fx-dependent: publishes a framework-dependent application (with an
application host when a runtime is specified).
* fx-dependent-no-exe: publishes a framework-dependent application without an
application host.
The default when publishing without a runtime specified is
`fx-dependent-no-exe`.
The default when publishing with a runtime specified is `self-contained`.
`fx-dependent` requires netcoreapp2.1 or later when a runtime is specified.
The `--self-contained` option is still supported, but is now hidden so that
users will be encouraged to move to the `--mode` option.
Fixes#6237.
There is no need to store relative path today. But some part of the system does not accept relative path and there is no indication if it is storing full path or not. This is the root cause of https://github.com/dotnet/cli/issues/9319
“someplace” means different full path for Path class on unix and Windows. And the mock file system uses real Path class. Change tests' setup to use essentially “TEMPATH/someplace” instead of “someplace”
This reverts commit f9b939fe89.
That fix caused a regression that prevented a single `/property` option to
define multiple properties using the `/property:First=foo;Second=bar` syntax.
Users that want literal semicolons in the property values should use escaped
quotes around the property value, e.g. `/property:Prop='"foo;bar;baz"'`.
Fixes#9369.
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 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.
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.
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 “:”.
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
This commit implements the `buildserver shutdown` command that can be used to
shutdown MSBuild, VB/C# compiler, and Razor build servers.
By default, all three build servers are shut down. Options can be passed to
shut down a subset of the build servers.
Fixes#8185.
This commit ensures the correct property (`ProjectTypeGuids`) is respected when
adding a project to a solution file.
Additionally, we now error if a project type GUID cannot be determined rather
than incorrectly mapping to the C# project type.
Enabled previously disabled tests that were waiting on upstream changes from
MSBuild and F#.
Fixes#5131.
Fixes#7742.
* Move some projects to netstandard2.0
* Use version agnostic $(TargetFrameworkIdentifier) property to make changing versions easier since we only care about .NET Framework vs .NET Standard
* Add missing project to solution file
* Update TestPackageProjects.targets to use netstandard2.0 on non-Windows
This commit implements the missing `--tool-path` option for the list tool
command. This enables the command to list locally installed tools.
Fixes#8803.
This commit fixes the tool package store such that it stores a full path
instead of, potentially, a relative path.
This prevents a relative path from inadvertently being passed to NuGet
during the restore and causing it to restore relative to the temp project
directory.
Fixes#8829.
Currently the list tool command tests, while localizing the column headers,
didn't properly take into account the fact that localized builds might produce
strings longer than the English versions of the column header strings. This
results in a mismatch of the actual from the expected due to additional column
padding.
The fix is to stop using a static expected table and do a simple calculation of
the expected table based on the length of the localized strings.
Fixes issue related to PR #8799.
Other than change source to source-feed and make it additional instead of exclusive. I changed source to be multiple. Because restore support multiple source https://github.com/Microsoft/dotnet/issues/361
As for mock. The offline feed and source feed is considered the same, so remove the category of “source”. I renamed source to “AdditionalFeed” because that is more accurate on implementation level.
Note:
NuGet feed don’t have order. Whichever responses the fastest, is the first.
No change on restore.
scripts/cli-test-env.sh change is due to mac 10.13 is finally added to RID graph. And it is “considered” one of the CLI supported RID
This commit fixes the ToolPackageInstaller tests so that they no longer modify
the current working directory. The directory being set is now being properly
passed in as an argument to override the default of the current working
directory.
Additionally, this commit also changes the package root to a temp location
rather than based off of the current working directory.
This commit attempts to filter the diagnostic messages emitted during tool
installation. The diagnostic messages may be prefixed with the temporary
project; since this is an implementation detail that only causes confusion and
clutter in the diagnostic messages, the prefix is removed if present.
Fixes#8707.
* Change to escape string via XML
* tool-path option -- "Session tool"
From the beginning design, shim and packageInstaller take package location from constructor and don't have assumption anymore. From previous discussion, tool-path will simply change global location to the one user want, and everything else is the same.
However, this "override" need to happen during the call, that means InstallToolCommand will create different shim and packageInstaller object according to the tool-path during the call instead of constructor DI.
* global package location change
* block of leading dot as command name
* Localization of tool-path option
This commit fixes the case sensitivity of tool package identifiers.
Previously the install and uninstall commands unintentionally required the tool
package ids to specified in all lowercase for the install / uninstall to work.
Fixes#8682.
* Installation type
* Product Type
* Libc Release and Version
* Catch all
* Fix test
* Fix mac test
* Extract class
* Remove CharSet
* Remove extraneous assignment
* Missing space
* Typo
* Fix comment XML
* CR feedback
This commit implements a simple printable table that can be used to display
tabular data.
The columns of the table can specify a maximum width which will cause the
column text to wrap around to the next line.
* Move some projects to netstandard2.0
* Use version agnostic $(TargetFrameworkIdentifier) property to make changing versions easier since we only care about .NET Framework vs .NET Standard
* Add missing project to solution file
* Update TestPackageProjects.targets to use netstandard2.0 on non-Windows
This commit implements the `uninstall tool` command.
The `uninstall tool` command is responsible for uninstalling global tools that
are installed with the `install tool` command.
This commit heavily refactors the ToolPackage and ShellShim namespaces to
better support the operations required for the uninstall command.
Several string resources have been updated to be more informative or to correct
oddly structured sentences.
This commit also fixes `--version` on the install command not supporting ranges
and wildcards.
Fixes#8549.
Issue #8485 is partially fixed by this commit (`--prerelease` is not yet
implemented).
Extract packages to DotnetTools folder under sdk/{version}
Add new resolver to discover it
Add test to enforce package structure. It will fail when the structure
changed
* dotnet/release/2.1.3xx:
Update to aspnetcore 2.1.0-preview1-28275 and react to feed layout changes (#8611)
"ExternalRestoreSources" needs to be set in the docker container (#8602)
Signing nupkg contents (Cli.Utils and MSBuildResolver) along with the rest of the compiled assemblies.
Use satellites from roslyn package, not cli-deps-satellites
Update to roslyn 2.7.0-beta3-62612-07 for 2.1.1xx
Support TildeSlash expand (#8589)
Port Kernel Version telemetry to preview1
Do not create a directory with a trailing space; it cannot be deleted by conventional methods. (#8587)
Consume generic aspnetcore rpm installers
Insert NuGet Build 4.6.0-rtm-4918 into cli
Adding roslyn to automatic dependency flow through maestro.
Fixing update dependency by using the new APIs. We broke this when we updated the version of VersionTools.
MSBuild 15.6.81
Update SDK to 2.1.300-preview1-62608-07
MSBuild 15.6.80
Conflicts:
build/DependencyVersions.props
test/Microsoft.DotNet.ShellShim.Tests/ShellShimMakerTests.cs
* release/2.1.3xx: (51 commits)
Removing all references to a static 'aspnetpatch' Nuget.Config (#8556)
Updating the MSI Installation Note message. Also had to shift components around slightly to make it fit.
Fixing recent CLI test failures around ASP.NETcore in the orchestrated build (#8553)
The BuildTasksFeedTool version and the VersionTools version should be in sync to prevent incompatabilities between these two packages.
Update to aspnetcore 2.1.0-preview1-28228
Adding the VBCSCompiler to the list of signed files due to crossgen.
Ensure ASP.NET Core is included in macos .pkg installer and update to 2.1.0-preview1-28226
Remove obsolete F# satellite package
MSBuild 15.6.76
Update F# to match dev15.6 preview 4
Excluding shared framework assemblies from the Roslyn folder in the SDK.
Insert NuGet Build 4.6.0-rtm-4880 into cli
Updating Roslyn to 2.7.0-beta3-62529-05.
Update fsharp compiler to match preview 4
Insert NuGet Build 4.6.0-rtm-4862 into cli
MSBuild 15.6.70
Insert NuGet Build 4.6.0-rtm-4859 into cli
MSBuild 15.6.69
Update package reference
update fsharp compiler to match vs2017.6 preview 3
...
Conflicts:
build/DependencyVersions.props
* Fixing recent CLI test failures around ASP.NETcore in the orchestrated build.
* Put back the dotnet-migrate test's 'tempaspnetpatch' Nuget.config
* Fixing typos...
* Make dotnet install tool atomic
Apply TransactionScope to tool install. It can handle the correct timing
of roll back and commit.
Convert existing ToolPackageObtainer and ShellShimMaker by passing logic
via lambda to an object that has IEnlistmentNotification interface. It
turns out the very clean.
Use .stage as staging place to verify of package content, and shim. It
should roll back when something is wrong. When there is ctrl-c, there
will be garbage in .stage folder but not the root of the package folder.
* release/2.1.3xx:
Infrastructure updates: CLI:master -> release/2.1.3xx (#8541)
Fixing the recent CLI test failures around ASP.NETcore in the orchestrated build: adding a 'dotnet-corefxlab' feed. (#8536)
Update BranchInfo.props
Update the branch info to be correct for 2.1
[Fixes#8511] Update ASP.NET Core certificate installation message
Excluding shared framework assemblies from the Roslyn folder in the SDK.
Updating Roslyn to 2.7.0-beta3-62529-06.
This commit adds the `--verbosity` option to the `install tool` command.
MSBuild/NuGet output is now controllable by the user and defaults to being "quiet".
This enables users to see warnings from NuGet that otherwise would be swallowed
unless NuGet returned a non-zero exit code. As a byproduct of this change, the
exception handling and error messages related to obtaining tool packages was
retooled. We no longer display `install tool` command line help for installation
failures, as it should only be displayed for command line syntax errors.
Fixes#8465.
* release/2.1.3xx:
Updating the WebSdk DependencyVersion to support local build
Fix non-fatal null exception when no extra parameters are passed.
Separate tool package and shim file location
Updating the CLI branding and version to 2.1.300.
* Conflicts
src/dotnet/commands/dotnet-install/dotnet-install-tool/InstallToolCommand.cs
run-build.ps1
build/Version.props
To ensure the mock has the same behavior the component has, run mock under the same tests the adapter has.
It is a common problem that moq has -- "everything is mocked out, you are not test anything"
* Integrate NuGet ask
* Update NuGet version. Rely on NuGet to filter TFM. And use asset.json to find entrypoint
* Update XML file to per TFM
* Add extra property to the fake project according to nuget
* Treat nuget fallback folder as offline cache for tool
* Require -g to install global tool
* Copy test asset during test project build
* Address code review on LockFileMatchChecker
* Get NETCorePlatformsImplicitPackageVersion from PackageDefinitions
* Edit and add missing loc
* Change LockFileMatchChecker to local function
* Adding comment
* Add to content instead of copy
* Download platform package instead
* disable SDK side implicit NuGetFallbackFolder
* merge loc
* Revert extra line
* use a prerelease platforms version that supports alpine
Implement a simple launcher tool for running new processes on Windows
- This application takes two parameters via the .exe.config configuration file
- entryPoint: required - the file path to the new process being launched
- runner: optional - the executable or interpretter used to launch the
entryPoint
- Update dotnet-install-tool to generate an exe instead of a batch script file
This change is to add Sdk.props and Sdk.targets of Microsoft.Docker.Sdk
into CLI. This unblocks the scenario where a VS solution contains a few
.NET Core projects as well as a docker-compose.dcproj project and people
want to build the solution from command line with .NET Core CLI. With
the Sdk.props and Sdk.targets being present in CLI, building
docker-compose.dcproj becomes no-op so it won't block building the other
.NET Core projects.
