* 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
* dotnet/release/2.0.0: (32 commits)
Update wix version (#8313)
Use explict and non-preview versions for the build DLL
Fixing a typo...
The 15.4.8 version of the Microsoft.Build.Runtime nuget package is currupt; use the replacement 15.4.8.1
Fix dotnet-install to check the right path for no-op installs when --shared-runtime is specified
Fixed a typo...
Nuget.config update to align with CLI:master - add comments in DependencyVersions.prop
Even more package dependency re-names...
Third pass clean-up of package names.
Second pass clean-up of package names; resequencing download.
Updating dependency version properties in alignment with sample orchestrated build file at: https://dotnetfeed.blob.core.windows.net/orchestrated/20171129-03/orchestration-metadata/PackageVersions.props
The access key is already resolved: 'CoreSetupBlobAccessTokenParam'
Fixed another typo...
Fixed typo...
The first pass will need the extra args [same as run-build.ps1].
Dependency Uptake: download and import a package version props file.
Accounting for MSRC builds with pre-set 'CoreSetupBlobRootUrl' and 'CoreSetupBlobAccessToke' properties.
Changes per code review...
The URL root will include the "dotnet" container; the structure will be identical after the "dotnet" container.
No passwords should be in the open as environmental variables.
...
Conflicts:
build/DependencyVersions.props
src/redist/redist.csproj
src/tool_msbuild/tool_msbuild.csproj
src/tool_roslyn/tool_roslyn.csproj
test/Microsoft.DotNet.Cli.Utils.Tests/Microsoft.DotNet.Cli.Utils.Tests.csproj
It is not currently possible when there is a -f|--framework argument because
we cannot force a TargetFramework global property on to the restore evaluation.
Doing so completely breaks restore by applying the TargetFramework to all
projects transitively. The correct behavior is to restore for all frameworks,
then build/publish/etc for the given target framework. Achieving that still
requires two distinct msbuild invocations.
This also changes the verbosity of implicit restore from quiet to that
of the subsequent command (default=minimal). Similar to global properties,
we cannot specify a distinct console verbosity for the /restore portion of
the overall execution. For consistency, we apply the same verbosity change
to the case where we still use two separate msbuild invocations.
This also fixes an issue where the separate restore invocation's msbuild log
would be overwritten by the subsequent command execution. However, this remains
unfixed in the case where we still use two separate msbuild invocations.
We were taking care to set the console verbosity to minimal, but
only when no verbosity argument is passed. However, the default
verbosity for all CLI msbuild commands is already minimal and so
we can just get out of the way.
Issue https://github.com/dotnet/cli/issues/7091
Add internal command dotnet internal-reportinstallsuccess. Before
Windows installer finishes, run this command instead of dotnet new. It
will trigger the first time experience as well as sending telemetry with
installer exe name.
This command blocks to ensure that the webservice call completes.
If the LZMA archive is missing, the first-run message is printed every time.
This commit fixes that.
Split the first-run message into two pieces:
- The first-run (welcome and telemetry) message is printed only once, no matter
whether the cache was primed or not.
- The cache-priming message is printed only if the cache is avaialble.
Otherwise skip the cache introduction and the ccache priming operation.
