[main] Update dependencies from dotnet/sdk
- Coherency Updates:
- Microsoft.WindowsDesktop.App.Ref: from 6.0.0-preview.3.21172.2 to 6.0.0-preview.4.21175.1 (parent: Microsoft.NET.Sdk)
- VS.Redist.Common.WindowsDesktop.SharedFramework.x64.6.0: from 6.0.0-preview.3.21172.2 to 6.0.0-preview.4.21175.1 (parent: Microsoft.NET.Sdk)
- VS.Redist.Common.NetCore.SharedFramework.x64.6.0: from 6.0.0-preview.3.21167.1 to 6.0.0-preview.4.21176.1 (parent: Microsoft.NET.Sdk)
- Microsoft.NETCore.App.Ref: from 6.0.0-preview.3.21167.1 to 6.0.0-preview.4.21176.1 (parent: Microsoft.NET.Sdk)
- Microsoft.NETCore.App.Runtime.win-x64: from 6.0.0-preview.3.21167.1 to 6.0.0-preview.4.21176.1 (parent: Microsoft.NET.Sdk)
- Microsoft.NETCore.App.Host.win-x64: from 6.0.0-preview.3.21167.1 to 6.0.0-preview.4.21176.1 (parent: Microsoft.NET.Sdk)
- Microsoft.NETCore.DotNetHostResolver: from 6.0.0-preview.3.21167.1 to 6.0.0-preview.4.21176.1 (parent: Microsoft.NET.Sdk)
- Microsoft.NETCore.Platforms: from 6.0.0-preview.3.21167.1 to 6.0.0-preview.4.21176.1 (parent: Microsoft.NET.Sdk)
- Microsoft.AspNetCore.App.Ref: from 6.0.0-preview.3.21172.8 to 6.0.0-preview.4.21176.2 (parent: Microsoft.NET.Sdk)
- Microsoft.AspNetCore.App.Ref.Internal: from 6.0.0-preview.3.21172.8 to 6.0.0-preview.4.21176.2 (parent: Microsoft.NET.Sdk)
- Microsoft.AspNetCore.App.Runtime.win-x64: from 6.0.0-preview.3.21172.8 to 6.0.0-preview.4.21176.2 (parent: Microsoft.NET.Sdk)
- VS.Redist.Common.AspNetCore.SharedFramework.x64.6.0: from 6.0.0-preview.3.21172.8 to 6.0.0-preview.4.21176.2 (parent: Microsoft.NET.Sdk)
- dotnet-dev-certs: from 6.0.0-preview.3.21172.8 to 6.0.0-preview.4.21176.2 (parent: Microsoft.NET.Sdk)
- dotnet-user-secrets: from 6.0.0-preview.3.21172.8 to 6.0.0-preview.4.21176.2 (parent: Microsoft.NET.Sdk)
- Microsoft.DotNet.Common.ItemTemplates: from 6.0.100-preview.3.21161.1 to 6.0.100-preview.4.21176.3 (parent: Microsoft.NET.Sdk)
- Microsoft.WindowsDesktop.App.Runtime.win-x64: from 6.0.0-preview.3.21172.2 to 6.0.0-preview.4.21175.1 (parent: Microsoft.NET.Sdk)
- Microsoft.WindowsDesktop.App.Runtime.win-x64: from 6.0.0-preview.3.21172.2 to 6.0.0-preview.4.21175.1 (parent: Microsoft.NET.Sdk)
- Microsoft.DotNet.Wpf.ProjectTemplates: from 6.0.0-preview.3.21171.2 to 6.0.0-preview.4.21174.2 (parent: Microsoft.WindowsDesktop.App.Runtime.win-x64)
- Microsoft.NET.ILLink.Tasks: from 6.0.100-preview.2.21172.2 to 6.0.100-preview.2.21174.1 (parent: Microsoft.NET.Sdk)
- Microsoft.Net.Compilers.Toolset: from 3.10.0-2.21173.26 to 3.10.0-2.21175.26 (parent: Microsoft.NET.Sdk)
- Microsoft.Build: from 16.10.0-preview-21173-01 to 16.10.0-preview-21175-01 (parent: Microsoft.NET.Sdk)
- Remove Android, iOS, and macCatalyst from CA1416 analyzer warnings
- Merge remote-tracking branch 'origin/main' into darc-main-3ea62347-a0cb-4e6d-8270-37add6b236fa
- Missed property use
* Move dotnet-sdk snaps from dotnet/runtime
Dotnet/runtime was the home of the snap files for both dotnet-runtime
dotnet dotnet-sdk snap files. Moving the dotnet-sdk snap files into
dotnet/installer next to the installers.
* Create CODEOWNERS
In our efforts to unify the build access story using aka.ms links, we have found that there are certain files that share the same name in multiple different repositories, most importantly, productVersion.txt. As part of the work to move to aka.ms links, we will be flattening the short link paths, so rather than having a runtime-specific, aspnetcore-specific, etc. full path to the files generated by each of the repos, they will all go to the same short link location. This means that the path to productVersion.txt will collide in the aka.ms links (the backing locations are not changing and will be unaffected). To combat this, we will add a duplicate of each of the product repos productVersion.txt, renamed to indicate which product repo it came from, in this case installer-productVersion.txt. The original will remane so that we do not break existing scenarios that do not use the aka.ms links.
In our efforts to unify the build access story using aka.ms links, we have found that there are certain files that share the same name in multiple different repositories, most importantly, productVersion.txt. As part of the work to move to aka.ms links, we will be flattening the short link paths, so rather than having a runtime-specific, aspnetcore-specific, etc. full path to the files generated by each of the repos, they will all go to the same short link location. This means that the path to productVersion.txt will collide in the aka.ms links (the backing locations are not changing and will be unaffected). To combat this, we will add a duplicate of each of the product repos productVersion.txt, renamed to indicate which product repo it came from, in this case installer-productVersion.txt. The original will remane so that we do not break existing scenarios that do not use the aka.ms links.
In our efforts to unify the build access story using aka.ms links, we have found that there are certain files that share the same name in multiple different repositories, most importantly, productVersion.txt. As part of the work to move to aka.ms links, we will be flattening the short link paths, so rather than having a runtime-specific, aspnetcore-specific, etc. full path to the files generated by each of the repos, they will all go to the same short link location. This means that the path to productVersion.txt will collide in the aka.ms links (the backing locations are not changing and will be unaffected). To combat this, we will add a duplicate of each of the product repos productVersion.txt, renamed to indicate which product repo it came from, in this case installer-productVersion.txt. The original will remane so that we do not break existing scenarios that do not use the aka.ms links.
Port #9475 to release/5.0.2xx
The linux-musl-arm RID in the GenerateBundledVersions.targets was accidentally
added in Net50RuntimePackRids instead of Net50AppHostRids. That caused a wrong
host (linux-arm) to be extracted during dotnet publish.
The linux-musl-arm RID in the GenerateBundledVersions.targets was accidentally
added in Net50RuntimePackRids instead of Net50AppHostRids. That caused a wrong
host (linux-arm) to be extracted during dotnet publish.
[master] Update dependencies from dotnet/sdk
- Coherency Updates:
- Microsoft.AspNetCore.App.Ref: from 6.0.0-alpha.1.20526.6 to 6.0.0-alpha.1.20561.2 (parent: Microsoft.NET.Sdk)
- Microsoft.AspNetCore.App.Ref.Internal: from 6.0.0-alpha.1.20526.6 to 6.0.0-alpha.1.20561.2 (parent: Microsoft.NET.Sdk)
- VS.Redist.Common.AspNetCore.SharedFramework.x64.6.0: from 6.0.0-alpha.1.20526.6 to 6.0.0-alpha.1.20561.2 (parent: Microsoft.NET.Sdk)
- Microsoft.EntityFrameworkCore: from 6.0.0-alpha.1.20509.5 to 6.0.0-alpha.1.20560.6 (parent: Microsoft.AspNetCore.App.Runtime.win-x64)
- Microsoft.AspNetCore.App.Runtime.win-x64: from 6.0.0-alpha.1.20526.6 to 6.0.0-alpha.1.20561.2 (parent: Microsoft.NET.Sdk)
- dotnet-dev-certs: from 6.0.0-alpha.1.20526.6 to 6.0.0-alpha.1.20561.2 (parent: Microsoft.NET.Sdk)
- dotnet-user-secrets: from 6.0.0-alpha.1.20526.6 to 6.0.0-alpha.1.20561.2 (parent: Microsoft.NET.Sdk)
- dotnet-watch: from 6.0.0-alpha.1.20526.6 to 6.0.0-alpha.1.20561.2 (parent: Microsoft.NET.Sdk)
- Update installer target framework to 6.0
- Install 5.0.0 and 3.1.0 runtime
- Merge remote-tracking branch 'upstream/master' into darc-master-4cce5096-36fd-4b94-ba12-5d198a821a27
- Update SDK to one that targets 6.0
- disable test as tool build for now
- Fix aspnet runtime RID
[release/5.0.2xx] Update dependencies from dotnet/sdk
- Coherency Updates:
- Microsoft.WindowsDesktop.App: from 5.0.0-rtm.20529.4 to 5.0.1-servicing.20562.1 (parent: Microsoft.NET.Sdk)
- Microsoft.DotNet.Common.ItemTemplates: from 5.0.0 to 5.0.0 (parent: Microsoft.NET.Sdk)
- Microsoft.WindowsDesktop.App.Runtime.win-x64: from 5.0.0 to 5.0.1 (parent: Microsoft.NET.Sdk)
- Microsoft.Dotnet.WinForms.ProjectTemplates: from 5.0.0-rtm.20529.3 to 5.0.1-servicing.20561.12 (parent: Microsoft.WindowsDesktop.App.Runtime.win-x64)
- Microsoft.WindowsDesktop.App.Runtime.win-x64: from 5.0.0 to 5.0.1 (parent: Microsoft.NET.Sdk)
- Microsoft.DotNet.Wpf.ProjectTemplates: from 5.0.0-rtm.20529.5 to 5.0.1-servicing.20561.15 (parent: Microsoft.WindowsDesktop.App.Runtime.win-x64)
- NuGet.Build.Tasks: from 5.8.0-rc.6930 to 5.9.0-preview.1.6955 (parent: Microsoft.NET.Sdk)
- Use non-stable location to find targeting pack version
- Fix windows desktop base url
* Update dependencies from https://github.com/dotnet/arcade build 20200924.4
Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Arcade.Sdk
From Version 5.0.0-beta.20471.1 -> To Version 5.0.0-beta.20474.4
Dependency coherency updates
Microsoft.WindowsDesktop.App.Ref,Microsoft.WindowsDesktop.App,Microsoft.AspNetCore.App.Ref,Microsoft.AspNetCore.App.Ref.Internal,Microsoft.AspNetCore.App.Runtime.win-x64,VS.Redist.Common.AspNetCore.TargetingPack.x64.5.0,dotnet-dev-certs,dotnet-user-secrets,dotnet-watch,Microsoft.Dotnet.WinForms.ProjectTemplates,Microsoft.WindowsDesktop.App.Runtime.win-x64,Microsoft.DotNet.Wpf.ProjectTemplates,Microsoft.FSharp.Compiler,Microsoft.NET.Test.Sdk,Microsoft.NET.ILLink.Tasks,Microsoft.Net.Compilers.Toolset,Microsoft.Build,NuGet.Build.Tasks
From Version 5.0.0-rc.2.20474.5 -> To Version 5.0.0-rc.1.20417.4 (parent: Microsoft.NET.Sdk
* Update dependencies from https://github.com/dotnet/arcade build 20200928.3
Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Arcade.Sdk
From Version 5.0.0-beta.20471.1 -> To Version 5.0.0-beta.20478.3
Dependency coherency updates
Microsoft.WindowsDesktop.App.Ref,Microsoft.WindowsDesktop.App,Microsoft.AspNetCore.App.Ref,Microsoft.AspNetCore.App.Ref.Internal,Microsoft.AspNetCore.App.Runtime.win-x64,VS.Redist.Common.AspNetCore.TargetingPack.x64.5.0,dotnet-dev-certs,dotnet-user-secrets,dotnet-watch,Microsoft.Dotnet.WinForms.ProjectTemplates,Microsoft.WindowsDesktop.App.Runtime.win-x64,Microsoft.DotNet.Wpf.ProjectTemplates,Microsoft.FSharp.Compiler,Microsoft.NET.Test.Sdk,Microsoft.NET.ILLink.Tasks,Microsoft.Net.Compilers.Toolset,Microsoft.Build,NuGet.Build.Tasks
From Version 5.0.0-rc.2.20474.5 -> To Version 5.0.0-rc.1.20417.4 (parent: Microsoft.NET.Sdk
* Update dependencies from https://github.com/dotnet/arcade build 20201006.7
Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Arcade.Sdk
From Version 5.0.0-beta.20471.1 -> To Version 5.0.0-beta.20506.7
Dependency coherency updates
Microsoft.WindowsDesktop.App.Ref,Microsoft.WindowsDesktop.App,Microsoft.AspNetCore.App.Ref,Microsoft.AspNetCore.App.Ref.Internal,Microsoft.AspNetCore.App.Runtime.win-x64,VS.Redist.Common.AspNetCore.TargetingPack.x64.5.0,dotnet-dev-certs,dotnet-user-secrets,dotnet-watch,Microsoft.Dotnet.WinForms.ProjectTemplates,Microsoft.WindowsDesktop.App.Runtime.win-x64,Microsoft.DotNet.Wpf.ProjectTemplates,Microsoft.FSharp.Compiler,Microsoft.NET.Test.Sdk,Microsoft.NET.ILLink.Tasks,Microsoft.Net.Compilers.Toolset,Microsoft.Build,NuGet.Build.Tasks,Microsoft.SourceLink.GitHub,XliffTasks
From Version 5.0.0-rc.2.20474.5 -> To Version 5.0.0-rc.1.20417.4 (parent: Microsoft.NET.Sdk
* Update dependencies from https://github.com/dotnet/arcade build 20201009.12
Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Arcade.Sdk
From Version 5.0.0-beta.20471.1 -> To Version 6.0.0-beta.20509.12
Dependency coherency updates
Microsoft.WindowsDesktop.App.Ref,Microsoft.WindowsDesktop.App,Microsoft.AspNetCore.App.Ref,Microsoft.AspNetCore.App.Ref.Internal,Microsoft.AspNetCore.App.Runtime.win-x64,VS.Redist.Common.AspNetCore.TargetingPack.x64.5.0,dotnet-dev-certs,dotnet-user-secrets,dotnet-watch,Microsoft.Dotnet.WinForms.ProjectTemplates,Microsoft.WindowsDesktop.App.Runtime.win-x64,Microsoft.DotNet.Wpf.ProjectTemplates,Microsoft.FSharp.Compiler,Microsoft.NET.Test.Sdk,Microsoft.NET.ILLink.Tasks,Microsoft.Net.Compilers.Toolset,Microsoft.Build,NuGet.Build.Tasks,Microsoft.SourceLink.GitHub,XliffTasks
From Version 5.0.0-rc.2.20474.5 -> To Version 5.0.0-rc.1.20417.4 (parent: Microsoft.NET.Sdk
* Update dependencies from https://github.com/dotnet/arcade build 20201020.8
Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Arcade.Sdk
From Version 5.0.0-beta.20471.1 -> To Version 6.0.0-beta.20520.8
Dependency coherency updates
Microsoft.SourceLink.GitHub,XliffTasks
From Version 1.1.0-beta-20464-02 -> To Version 1.1.0-beta-20519-02 (parent: Microsoft.DotNet.Arcade.Sdk
* Update FileInfoAssertions.cs
* Update FileInfoAssertions.cs
* Use tasks provided by Microsoft.DotNet.Build.Tasks.Installers when provided.
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>
Co-authored-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
* Revert "Create ARM64 verision of bundle theme file to account for lack of WindowsDesktop support"
This reverts commit d590b93a1b.
* Include WindowsDesktop assets in the arm64 bundled installer
* Download ARM64 WindowsDesktop msi
* Enable post build signing
Enables post build signing of installer by including the items that need to be signed
post build in an ItemsToSignPostBuild item group and moving the file signing information
into the Signing.props files.
Changes to in-build signing have been verified by taking a drop with the current in-build
structure and comparing the the signatures and strong name keys between files
in equivalent builds.
* Enable post build signing
Enables post build signing of installer by including the items that need to be signed
post build in an ItemsToSignPostBuild item group and moving the file signing information
into the Signing.props files.
Changes to in-build signing have been verified by taking a drop with the current in-build
structure and comparing the the signatures and strong name keys between files
in equivalent builds.
Co-authored-by: dotnet-bot <dotnet-bot@dotnetfoundation.org>
Co-authored-by: Christopher Costa <chcosta@microsoft.com>
This change is required for RTM stable builds. When stable versions are generated the CalculateTemplateVersions task will fail.
For .NET 3.x, installer is partially on arcade. It uses its own versioning model, but the arcade generated versions are actually set (specifically VersionSuffix). So even when stable builds are generated, VersionSuffix is available. It is unused when the aspnetcore template versions are stable.
For .NET 5, installer is now fully on arcade versioning, which means VersionSuffix is not set when stable versions are generated.
Instead of using installer's version suffix if aspnetcore's template versions are unstable, use the version suffix of the aspnetcore template versions. This subtley affects the installer directory of the templates:
If the aspnetcore version is: 5.0.0-rc.1.1234.5
And the installer version is: 5.0.100-rc.1.9999.9
Then:
Template install dir before this change: .dotnet\templates\5.0.0-rc.1.9999.9
Template install dir after this change: .dotnet\templates\5.0.0-rc.1.1234.5
Of note: The overall template layout doesn't make a ton of sense. The aspnetcore template version is used for the install directory, but many different templates are put in this directory, including some that have completely different versions.
The installer currently updates all runtimeconfig files with the M.NETCore.App version
regardless of the runtime they are targeting. This causes issues with dotnet-watch
which is targeting the AspNetCore shared runtime as of 5.0-preview8. This change
updates the targets \ task to be more discerning.
[release/5.0.1xx-rc2] Update dependencies from dotnet/sdk
- Coherency Updates:
- Microsoft.WindowsDesktop.App.Ref: from 5.0.0-rc.1.20431.13 to 5.0.0-rc.2.20454.1 (parent: Microsoft.NET.Sdk)
- Microsoft.WindowsDesktop.App: from 5.0.0-rc.1.20431.13 to 5.0.0-rc.2.20454.1 (parent: Microsoft.NET.Sdk)
- Microsoft.NETCore.App.Ref: from 5.0.0-rc.1.20431.14 to 5.0.0-rc.2.20454.25 (parent: Microsoft.NET.Sdk)
- Microsoft.NETCore.App.Internal: from 5.0.0-rc.1.20431.14 to 5.0.0-rc.2.20454.25 (parent: Microsoft.NET.Sdk)
- Microsoft.NETCore.App.Runtime.win-x64: from 5.0.0-rc.1.20431.14 to 5.0.0-rc.2.20454.25 (parent: Microsoft.NET.Sdk)
- Microsoft.NETCore.App.Host.win-x64: from 5.0.0-rc.1.20431.14 to 5.0.0-rc.2.20454.25 (parent: Microsoft.NET.Sdk)
- Microsoft.NETCore.DotNetHostResolver: from 5.0.0-rc.1.20431.14 to 5.0.0-rc.2.20454.25 (parent: Microsoft.NET.Sdk)
- Microsoft.NETCore.Platforms: from 5.0.0-rc.1.20431.14 to 5.0.0-rc.2.20454.25 (parent: Microsoft.NET.Sdk)
- Microsoft.AspNetCore.App.Ref: from 5.0.0-rc.1.20451.2 to 5.0.0-rc.2.20456.3 (parent: Microsoft.NET.Sdk)
- Microsoft.AspNetCore.App.Runtime.win-x64: from 5.0.0-rc.1.20451.2 to 5.0.0-rc.2.20456.3 (parent: Microsoft.NET.Sdk)
- VS.Redist.Common.AspNetCore.TargetingPack.x64.5.0: from 5.0.0-rc.1.20451.2 to 5.0.0-rc.2.20456.3 (parent: Microsoft.NET.Sdk)
- dotnet-dev-certs: from 5.0.0-rc.1.20451.2 to 5.0.0-rc.2.20456.3 (parent: Microsoft.NET.Sdk)
- dotnet-user-secrets: from 5.0.0-rc.1.20451.2 to 5.0.0-rc.2.20456.3 (parent: Microsoft.NET.Sdk)
- dotnet-watch: from 5.0.0-rc.1.20451.2 to 5.0.0-rc.2.20456.3 (parent: Microsoft.NET.Sdk)
- Microsoft.Dotnet.WinForms.ProjectTemplates: from 5.0.0-rc.1.20431.1 to 5.0.0-rc.1.20451.14 (parent: Microsoft.WindowsDesktop.App.Runtime.win-x64)
- Microsoft.WindowsDesktop.App.Runtime.win-x64: from 5.0.0-rc.1.20431.13 to 5.0.0-rc.2.20454.1 (parent: Microsoft.NET.Sdk)
- Microsoft.DotNet.Wpf.ProjectTemplates: from 5.0.0-rc.1.20431.2 to 5.0.0-rc.2.20452.6 (parent: Microsoft.WindowsDesktop.App.Runtime.win-x64)
- Microsoft.FSharp.Compiler: from 11.0.0-beta.20428.2 to 11.0.0-beta.20457.3 (parent: Microsoft.NET.Sdk)
- Microsoft.NET.Test.Sdk: from 16.8.0-release-20200828-02 to 16.8.0-release-20200902-05 (parent: Microsoft.NET.Sdk)
- Microsoft.Net.Compilers.Toolset: from 3.8.0-3.20420.1 to 3.8.0-3.20454.4 (parent: Microsoft.NET.Sdk)
- Microsoft.Build: from 16.8.0-preview-20429-01 to 16.8.0-preview-20454-01 (parent: Microsoft.NET.Sdk)
- NuGet.Build.Tasks: from 5.8.0-preview.3.6783 to 5.8.0-preview.3.6812 (parent: Microsoft.NET.Sdk)
- Microsoft.DotNet.Cli.CommandLine: from 1.0.0-preview.19208.1 to 1.0.0-preview.19208.1 (parent: Microsoft.NET.Sdk)
- Updates:
- Microsoft.NET.Sdk: from 5.0.100-rc.1.20451.7 to 5.0.100-rc.2.20458.1
- Microsoft.DotNet.MSBuildSdkResolver: from 5.0.100-rc.1.20451.7 to 5.0.100-rc.2.20458.1
- Microsoft.WindowsDesktop.App.Ref: from 5.0.0-rc.1.20431.13 to 5.0.0-rc.2.20454.1
- Microsoft.WindowsDesktop.App: from 5.0.0-rc.1.20431.13 to 5.0.0-rc.2.20454.1
- Microsoft.NETCore.App.Ref: from 5.0.0-rc.1.20431.14 to 5.0.0-rc.2.20454.25
- Microsoft.NETCore.App.Internal: from 5.0.0-rc.1.20431.14 to 5.0.0-rc.2.20454.25
- Microsoft.NETCore.App.Runtime.win-x64: from 5.0.0-rc.1.20431.14 to 5.0.0-rc.2.20454.25
- Microsoft.NETCore.App.Host.win-x64: from 5.0.0-rc.1.20431.14 to 5.0.0-rc.2.20454.25
- Microsoft.NETCore.DotNetHostResolver: from 5.0.0-rc.1.20431.14 to 5.0.0-rc.2.20454.25
- Microsoft.NETCore.Platforms: from 5.0.0-rc.1.20431.14 to 5.0.0-rc.2.20454.25
- Microsoft.AspNetCore.App.Ref: from 5.0.0-rc.1.20451.2 to 5.0.0-rc.2.20456.3
- Microsoft.AspNetCore.App.Runtime.win-x64: from 5.0.0-rc.1.20451.2 to 5.0.0-rc.2.20456.3
- VS.Redist.Common.AspNetCore.TargetingPack.x64.5.0: from 5.0.0-rc.1.20451.2 to 5.0.0-rc.2.20456.3
- dotnet-dev-certs: from 5.0.0-rc.1.20451.2 to 5.0.0-rc.2.20456.3
- dotnet-user-secrets: from 5.0.0-rc.1.20451.2 to 5.0.0-rc.2.20456.3
- dotnet-watch: from 5.0.0-rc.1.20451.2 to 5.0.0-rc.2.20456.3
- Microsoft.Dotnet.WinForms.ProjectTemplates: from 5.0.0-rc.1.20431.1 to 5.0.0-rc.1.20451.14
- Microsoft.WindowsDesktop.App.Runtime.win-x64: from 5.0.0-rc.1.20431.13 to 5.0.0-rc.2.20454.1
- Microsoft.DotNet.Wpf.ProjectTemplates: from 5.0.0-rc.1.20431.2 to 5.0.0-rc.2.20452.6
- Microsoft.FSharp.Compiler: from 11.0.0-beta.20428.2 to 11.0.0-beta.20457.3
- Microsoft.NET.Test.Sdk: from 16.8.0-release-20200828-02 to 16.8.0-release-20200902-05
- Microsoft.Net.Compilers.Toolset: from 3.8.0-3.20420.1 to 3.8.0-3.20454.4
- Microsoft.Build: from 16.8.0-preview-20429-01 to 16.8.0-preview-20454-01
- NuGet.Build.Tasks: from 5.8.0-preview.3.6783 to 5.8.0-preview.3.6812
- Microsoft.DotNet.Cli.CommandLine: from 1.0.0-preview.19208.1 to 1.0.0-preview.19208.1
- Exclusing all reference assemblies from crossgen
- Removing extra /
* Update dependencies from https://github.com/dotnet/sdk build 20200831.11
Microsoft.NET.Sdk , Microsoft.DotNet.MSBuildSdkResolver
From Version 5.0.100-rc.1.20431.8 -> To Version 5.0.100-rc.1.20431.11
* Update dependencies from https://github.com/dotnet/sdk build 20200831.12
Microsoft.NET.Sdk , Microsoft.DotNet.MSBuildSdkResolver
From Version 5.0.100-rc.1.20431.8 -> To Version 5.0.100-rc.1.20431.12
Dependency coherency updates
Microsoft.NETCore.App.Ref,Microsoft.NETCore.App.Internal,Microsoft.NETCore.App.Runtime.win-x64,Microsoft.NETCore.App.Host.win-x64,Microsoft.NETCore.DotNetHostResolver,Microsoft.NETCore.Platforms
From Version 5.0.0-rc.1.20431.5 -> To Version 5.0.0-rc.1.20431.7 (parent: Microsoft.NET.Sdk
* Update dependencies from https://github.com/dotnet/sdk build 20200831.13
Microsoft.NET.Sdk , Microsoft.DotNet.MSBuildSdkResolver
From Version 5.0.100-rc.1.20431.8 -> To Version 5.0.100-rc.1.20431.13
Dependency coherency updates
Microsoft.NETCore.App.Ref,Microsoft.NETCore.App.Internal,Microsoft.NETCore.App.Runtime.win-x64,Microsoft.NETCore.App.Host.win-x64,Microsoft.NETCore.DotNetHostResolver,Microsoft.NETCore.Platforms,Microsoft.DotNet.Common.ItemTemplates
From Version 5.0.0-rc.1.20431.5 -> To Version 5.0.0-rc.1.20431.7 (parent: Microsoft.NET.Sdk
* Update dependencies from https://github.com/dotnet/sdk build 20200831.15
Microsoft.NET.Sdk , Microsoft.DotNet.MSBuildSdkResolver
From Version 5.0.100-rc.1.20431.8 -> To Version 5.0.100-rc.1.20431.15
Dependency coherency updates
Microsoft.NETCore.App.Ref,Microsoft.NETCore.App.Internal,Microsoft.NETCore.App.Runtime.win-x64,Microsoft.NETCore.App.Host.win-x64,Microsoft.NETCore.DotNetHostResolver,Microsoft.NETCore.Platforms,Microsoft.DotNet.Common.ItemTemplates
From Version 5.0.0-rc.1.20431.5 -> To Version 5.0.0-rc.1.20431.7 (parent: Microsoft.NET.Sdk
* Update dependencies from https://github.com/dotnet/sdk build 20200831.18
Microsoft.NET.Sdk , Microsoft.DotNet.MSBuildSdkResolver
From Version 5.0.100-rc.1.20431.8 -> To Version 5.0.100-rc.1.20431.18
Dependency coherency updates
Microsoft.NETCore.App.Ref,Microsoft.NETCore.App.Internal,Microsoft.NETCore.App.Runtime.win-x64,Microsoft.NETCore.App.Host.win-x64,Microsoft.NETCore.DotNetHostResolver,Microsoft.NETCore.Platforms,Microsoft.AspNetCore.App.Ref,Microsoft.AspNetCore.App.Runtime.win-x64,VS.Redist.Common.AspNetCore.TargetingPack.x64.5.0,dotnet-dev-certs,dotnet-user-secrets,dotnet-watch,Microsoft.DotNet.Common.ItemTemplates
From Version 5.0.0-rc.1.20431.5 -> To Version 5.0.0-rc.1.20431.7 (parent: Microsoft.NET.Sdk
* Update dependencies from https://github.com/dotnet/sdk build 20200901.1
Microsoft.NET.Sdk , Microsoft.DotNet.MSBuildSdkResolver
From Version 5.0.100-rc.1.20431.8 -> To Version 5.0.100-rc.1.20451.1
Dependency coherency updates
Microsoft.NETCore.App.Ref,Microsoft.NETCore.App.Internal,Microsoft.NETCore.App.Runtime.win-x64,Microsoft.NETCore.App.Host.win-x64,Microsoft.NETCore.DotNetHostResolver,Microsoft.NETCore.Platforms,Microsoft.AspNetCore.App.Ref,Microsoft.AspNetCore.App.Runtime.win-x64,VS.Redist.Common.AspNetCore.TargetingPack.x64.5.0,dotnet-dev-certs,dotnet-user-secrets,dotnet-watch,Microsoft.DotNet.Common.ItemTemplates
From Version 5.0.0-rc.1.20431.5 -> To Version 5.0.0-rc.1.20431.14 (parent: Microsoft.NET.Sdk
* Update dependencies from https://github.com/dotnet/sdk build 20200901.2
Microsoft.NET.Sdk , Microsoft.DotNet.MSBuildSdkResolver
From Version 5.0.100-rc.1.20431.8 -> To Version 5.0.100-rc.1.20451.2
Dependency coherency updates
Microsoft.NETCore.App.Ref,Microsoft.NETCore.App.Internal,Microsoft.NETCore.App.Runtime.win-x64,Microsoft.NETCore.App.Host.win-x64,Microsoft.NETCore.DotNetHostResolver,Microsoft.NETCore.Platforms,Microsoft.AspNetCore.App.Ref,Microsoft.AspNetCore.App.Runtime.win-x64,VS.Redist.Common.AspNetCore.TargetingPack.x64.5.0,dotnet-dev-certs,dotnet-user-secrets,dotnet-watch,Microsoft.DotNet.Common.ItemTemplates
From Version 5.0.0-rc.1.20431.5 -> To Version 5.0.0-rc.1.20431.14 (parent: Microsoft.NET.Sdk
* Update dependencies from https://github.com/dotnet/sdk build 20200901.3
Microsoft.NET.Sdk , Microsoft.DotNet.MSBuildSdkResolver
From Version 5.0.100-rc.1.20431.8 -> To Version 5.0.100-rc.1.20451.3
Dependency coherency updates
Microsoft.NETCore.App.Ref,Microsoft.NETCore.App.Internal,Microsoft.NETCore.App.Runtime.win-x64,Microsoft.NETCore.App.Host.win-x64,Microsoft.NETCore.DotNetHostResolver,Microsoft.NETCore.Platforms,Microsoft.AspNetCore.App.Ref,Microsoft.AspNetCore.App.Runtime.win-x64,VS.Redist.Common.AspNetCore.TargetingPack.x64.5.0,dotnet-dev-certs,dotnet-user-secrets,dotnet-watch,Microsoft.DotNet.Common.ItemTemplates
From Version 5.0.0-rc.1.20431.5 -> To Version 5.0.0-rc.1.20431.14 (parent: Microsoft.NET.Sdk
* Update dependencies from https://github.com/dotnet/sdk build 20200901.4
Microsoft.NET.Sdk , Microsoft.DotNet.MSBuildSdkResolver
From Version 5.0.100-rc.1.20431.8 -> To Version 5.0.100-rc.1.20451.4
Dependency coherency updates
Microsoft.WindowsDesktop.App.Ref,Microsoft.WindowsDesktop.App,Microsoft.NETCore.App.Ref,Microsoft.NETCore.App.Internal,Microsoft.NETCore.App.Runtime.win-x64,Microsoft.NETCore.App.Host.win-x64,Microsoft.NETCore.DotNetHostResolver,Microsoft.NETCore.Platforms,Microsoft.AspNetCore.App.Ref,Microsoft.AspNetCore.App.Runtime.win-x64,VS.Redist.Common.AspNetCore.TargetingPack.x64.5.0,dotnet-dev-certs,dotnet-user-secrets,dotnet-watch,Microsoft.DotNet.Common.ItemTemplates,Microsoft.Dotnet.WinForms.ProjectTemplates,Microsoft.WindowsDesktop.App.Runtime.win-x64,Microsoft.DotNet.Wpf.ProjectTemplates
From Version 5.0.0-rc.1.20430.1 -> To Version 5.0.0-rc.1.20431.13 (parent: Microsoft.NET.Sdk
* Update dependencies from https://github.com/dotnet/sdk build 20200901.5
Microsoft.NET.Sdk , Microsoft.DotNet.MSBuildSdkResolver
From Version 5.0.100-rc.1.20431.8 -> To Version 5.0.100-rc.1.20451.5
Dependency coherency updates
Microsoft.WindowsDesktop.App.Ref,Microsoft.WindowsDesktop.App,Microsoft.NETCore.App.Ref,Microsoft.NETCore.App.Internal,Microsoft.NETCore.App.Runtime.win-x64,Microsoft.NETCore.App.Host.win-x64,Microsoft.NETCore.DotNetHostResolver,Microsoft.NETCore.Platforms,Microsoft.AspNetCore.App.Ref,Microsoft.AspNetCore.App.Runtime.win-x64,VS.Redist.Common.AspNetCore.TargetingPack.x64.5.0,dotnet-dev-certs,dotnet-user-secrets,dotnet-watch,Microsoft.DotNet.Common.ItemTemplates,Microsoft.Dotnet.WinForms.ProjectTemplates,Microsoft.WindowsDesktop.App.Runtime.win-x64,Microsoft.DotNet.Wpf.ProjectTemplates
From Version 5.0.0-rc.1.20430.1 -> To Version 5.0.0-rc.1.20431.13 (parent: Microsoft.NET.Sdk
* Fix SDK toolset zip base uri
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Matt Mitchell <mmitche@microsoft.com>
[master] Update dependencies from dotnet/sdk
- Coherency Updates:
- Microsoft.WindowsDesktop.App.Ref: from 5.0.0-rc.1.20405.1 to 5.0.0-rc.1.20417.4 (parent: Microsoft.NET.Sdk)
- Microsoft.WindowsDesktop.App: from 5.0.0-rc.1.20405.1 to 5.0.0-rc.1.20417.4 (parent: Microsoft.NET.Sdk)
- Microsoft.NETCore.App.Ref: from 5.0.0-rc.1.20404.16 to 5.0.0-rc.1.20417.14 (parent: Microsoft.NET.Sdk)
- Microsoft.NETCore.App.Internal: from 5.0.0-rc.1.20404.16 to 5.0.0-rc.1.20417.14 (parent: Microsoft.NET.Sdk)
- Microsoft.NETCore.App.Runtime.win-x64: from 5.0.0-rc.1.20404.16 to 5.0.0-rc.1.20417.14 (parent: Microsoft.NET.Sdk)
- Microsoft.NETCore.App.Host.win-x64: from 5.0.0-rc.1.20404.16 to 5.0.0-rc.1.20417.14 (parent: Microsoft.NET.Sdk)
- Microsoft.NETCore.DotNetHostResolver: from 5.0.0-rc.1.20404.16 to 5.0.0-rc.1.20417.14 (parent: Microsoft.NET.Sdk)
- Microsoft.NETCore.Platforms: from 5.0.0-rc.1.20404.16 to 5.0.0-rc.1.20417.14 (parent: Microsoft.NET.Sdk)
- Microsoft.AspNetCore.App.Ref: from 5.0.0-rc.1.20405.9 to 5.0.0-rc.1.20418.28 (parent: Microsoft.NET.Sdk)
- Microsoft.AspNetCore.App.Runtime.win-x64: from 5.0.0-rc.1.20405.9 to 5.0.0-rc.1.20418.28 (parent: Microsoft.NET.Sdk)
- VS.Redist.Common.AspNetCore.TargetingPack.x64.5.0: from 5.0.0-rc.1.20405.9 to 5.0.0-rc.1.20418.28 (parent: Microsoft.NET.Sdk)
- dotnet-dev-certs: from 5.0.0-rc.1.20405.9 to 5.0.0-rc.1.20418.28 (parent: Microsoft.NET.Sdk)
- dotnet-user-secrets: from 5.0.0-rc.1.20405.9 to 5.0.0-rc.1.20418.28 (parent: Microsoft.NET.Sdk)
- dotnet-watch: from 5.0.0-rc.1.20405.9 to 5.0.0-rc.1.20418.28 (parent: Microsoft.NET.Sdk)
- Microsoft.DotNet.Common.ItemTemplates: from 5.0.0-rc.1.20407.1 to 5.0.0-rc.1.20407.2 (parent: Microsoft.NET.Sdk)
- Microsoft.Dotnet.WinForms.ProjectTemplates: from 5.0.0-rc.1.20370.3 to 5.0.0-rc.1.20417.1 (parent: Microsoft.WindowsDesktop.App.Runtime.win-x64)
- Microsoft.WindowsDesktop.App.Runtime.win-x64: from 5.0.0-rc.1.20405.1 to 5.0.0-rc.1.20417.4 (parent: Microsoft.NET.Sdk)
- Microsoft.DotNet.Wpf.ProjectTemplates: from 5.0.0-rc.1.20405.1 to 5.0.0-rc.1.20417.3 (parent: Microsoft.WindowsDesktop.App.Runtime.win-x64)
- Updates:
- Microsoft.DotNet.MSBuildSdkResolver: from 5.0.100-rc.1.20407.9 to 5.0.100-rc.1.20419.19
- Microsoft.NET.Sdk: from 5.0.100-rc.1.20407.9 to 5.0.100-rc.1.20419.19
- Microsoft.WindowsDesktop.App.Ref: from 5.0.0-rc.1.20405.1 to 5.0.0-rc.1.20417.4
- Microsoft.WindowsDesktop.App: from 5.0.0-rc.1.20405.1 to 5.0.0-rc.1.20417.4
- Microsoft.NETCore.App.Ref: from 5.0.0-rc.1.20404.16 to 5.0.0-rc.1.20417.14
- Microsoft.NETCore.App.Internal: from 5.0.0-rc.1.20404.16 to 5.0.0-rc.1.20417.14
- Microsoft.NETCore.App.Runtime.win-x64: from 5.0.0-rc.1.20404.16 to 5.0.0-rc.1.20417.14
- Microsoft.NETCore.App.Host.win-x64: from 5.0.0-rc.1.20404.16 to 5.0.0-rc.1.20417.14
- Microsoft.NETCore.DotNetHostResolver: from 5.0.0-rc.1.20404.16 to 5.0.0-rc.1.20417.14
- Microsoft.NETCore.Platforms: from 5.0.0-rc.1.20404.16 to 5.0.0-rc.1.20417.14
- Microsoft.AspNetCore.App.Ref: from 5.0.0-rc.1.20405.9 to 5.0.0-rc.1.20418.28
- Microsoft.AspNetCore.App.Runtime.win-x64: from 5.0.0-rc.1.20405.9 to 5.0.0-rc.1.20418.28
- VS.Redist.Common.AspNetCore.TargetingPack.x64.5.0: from 5.0.0-rc.1.20405.9 to 5.0.0-rc.1.20418.28
- dotnet-dev-certs: from 5.0.0-rc.1.20405.9 to 5.0.0-rc.1.20418.28
- dotnet-user-secrets: from 5.0.0-rc.1.20405.9 to 5.0.0-rc.1.20418.28
- dotnet-watch: from 5.0.0-rc.1.20405.9 to 5.0.0-rc.1.20418.28
- Microsoft.DotNet.Common.ItemTemplates: from 5.0.0-rc.1.20407.1 to 5.0.0-rc.1.20407.2
- Microsoft.Dotnet.WinForms.ProjectTemplates: from 5.0.0-rc.1.20370.3 to 5.0.0-rc.1.20417.1
- Microsoft.WindowsDesktop.App.Runtime.win-x64: from 5.0.0-rc.1.20405.1 to 5.0.0-rc.1.20417.4
- Microsoft.DotNet.Wpf.ProjectTemplates: from 5.0.0-rc.1.20405.1 to 5.0.0-rc.1.20417.3
- Address corssgen target issues
- Merge branch 'darc-master-2e4e2d61-f78f-4bde-8947-ee1fee18e9a9' of https://github.com/dotnet/core-sdk into darc-master-2e4e2d61-f78f-4bde-8947-ee1fee18e9a9
- Merge branch 'master' of https://github.com/dotnet/core-sdk into darc-master-2e4e2d61-f78f-4bde-8947-ee1fee18e9a9
Call tasks to gather light command packages after the build of each
installer. The way this is implemented is not ideal. Because powershell
scripts are used to invoke the WiX toolset, the light command package
info must be kept in sync. That said, the command lines and input files
do not change very often.
It's also on the table for .NET 6 to change around and unify the WiX
calls between the repos.
This also changes around the batching for the template MSIs to be compatible
with the call to the light command task
Makes the following artifacts non-shipping:
- template msis
- sdkplaceholders
- sdk-internal archives
For now these have been preserved as non-shipping rather than not published at all.
They all get packaged up in the VS insertion nupkgs, so I think in reality we don't need them at all.
* Remove references to PlatformAbstractions.
This will allow us to remove the PlatformAbstractions library from dotnet/runtime.
Contributes to https://github.com/dotnet/runtime/issues/3470
* Publish productVersion sparsely
Do not publish the productVersion file in every leg. Publish only in win-x64,
so that we don't end up uploading it for every manifest. Publishing breaks in this scenario today.
This is a real bug in publishing, but we will probably tighten the restrictions in the
Publish to BAR step so that multi-publishign the same asset is an error.
Also remove the productCommit-* in cases where we have overlapping rids, which would cause the same problem
* Set TLS1.2 before running dotnet-install in tests
The new powershell process overrides the setting that build.ps1 sets up.
* Reduce logging verbosity
Disable SDK tests that do 2.1.x self-contained
Delete GivenSelfContainedAppsRollForward. It doesn't work with 3.x+ already and won't work with 2.x MSRCs.
Disable SDK tests that do 2.1.x self-contained
Delete GivenSelfContainedAppsRollForward. It doesn't work with 3.x+ already and won't work with 2.x MSRCs.
* Pin dependency on Core-Setup ref packs to 3.1.0
* Fixup core-setup feeds
* Move pinned deps later in file
* Update GenerateLayout to account for pinned packs
Do not use the CDN as this can cause caching issues if bits have to be overwritten (which should not happen automatically, but may happen manually in certain cases)
With this commit, I can build core-sdk on RHEL 8 on arm64 directly,
without cross compilation.
Bump the sourcelink version to pick up the ability to parse git info
without depending on libgit2sharp. This allows sourcelink to work on
arm64. The version is the same as the one recently added to core-setup:
https://github.com/dotnet/core-setup/pull/7696
Introduce a new 'BuildArchitecture' msbuild property that contains the host
architecture (arm64, x64, etc). This is the architecture of the
currently running machine, and may be different from the architecture we
are targetting in the case of cross compilation.
There's a gotcha with BuildArchitecture: under Visual Studio (an x86) process,
we generally want a x64 architecture. So try and restrict it to arm64 only.
Use BuildArchitecture to determine whether _crossDir and LibCLRJitRid need to
be special-cased for arm64 or or not.
- issued new v1.6.4 for .NET Core 3 with updated dependencies versions
- issued new v1.7.0 wih support for .NET Core 3.1 targeting, netcoreapp3.1 is the default targeting since that version
We were bumping targeting pack, framework-dependent default
runtime version, and self-contained default (latest) runtime
version in unison. This only works for previews where these
versions are all the same always. Now that we're servicing 3.0,
we:
1. Pin targeting packs to 3.0.0
2. Fix default framework-dependent runtime version at 3.0.0
This change also:
* Removes dependencies on legacy/internal netcoreapp packages. We
now use Microsoft.NETCore.App.Internal version exclusively to
calculate the blob storage path for core-setup.
* Uses PackageDownload for all templates, including
latest. PackageReference had been used for latest only because
it hid another bug with the netcoreapp reference of
redist.csproj that is fixed here. That reference is now a
FrameworkReference as it should be.
* Removes a bunch of shenanigans from
GenerateBundledVersions.props that were causing issues with
above. One casualty of that is that we hard code the RID lists
for runtime pack, which I don't think is too bad, and actually
will make it easier to merge in source build patches.
* Cleans up how runtime and targeting pack versions are
referenced throughout, removing incorrect assumptions about
them being the same.
* Incorporates a prior closed PR to use suffixed version for blob
storage, even when assets coming from blob storage are
stabilized. It needed changes to merge with this.
Note:
* A similar theoretical servicing issue exists for the versions
of apphost, hostfxr, shared host, which are still assumed to be
the same as the runtime version in several places. If we choose
to service those independently, more work is required.
* There will be a 3.0.1 ASP.NET targeting pack, and so we will
have to unpin that once it is ready. This change establishes
the baseline of all targeting packs being pinnned, and they can
be unpinned in the (hopefully rare) cases where they need to be
serviced.
* Download core-setup files from MSRC storage
Add support for downloading core-setup files from an authenticated endpoint
* Update GenerateLayout.targets
* Adding changes to pass SAS token around
* Add credential provider to Dockerfile's
* Update after PR feedback
* Add comments about approach
* Copy NuGet config variables
* Update dependencies from https://github.com/dotnet/arcade build 20190924.3
- Microsoft.DotNet.Arcade.Sdk - 1.0.0-beta.19474.3
* Update NuGet.config
* React to NuGet design change for PackageDownload with multiple versions
A single item must be used with semicolon-delimited versions.
* Updating branding to 3.0.1-servicing
Also removed the DropSuffix so that we stop producing final branded builds for now.
* Address code review comments
Set DropSuffix to false instead of removing it.
* Fix resource branding
The resource branding for MicrosoftNETCoreApp and the Windows desktop runtime does not come from the same properties any longer. Use appropriate properties instead.
* Fix Linux native installer branding
The property in the bundled version props file installed with the SDK is _NETCoreSdkIsPreview. We use the same property name to define this value when creating the props file. We build with a preview version of the SDK. Because this is set by the preview SDK, and already has a value, we will not reset it when DropSuffix=true. It will simply remain 'true'. Thus we will simply propagate that existing value into the new props file. To fix, change the property name.
* Update dependencies from https://github.com/dotnet/core-setup build 20190913.05
- Microsoft.NETCore.App - 3.0.0-rc2-19463-05
- NETStandard.Library.Ref - 2.1.0
- Microsoft.WindowsDesktop.App - 3.0.0-rc2-19463-05
Dependency coherency updates
- Microsoft.Dotnet.WinForms.ProjectTemplates - 4.8.0-rc2.19462.10 (parent: Microsoft.WindowsDesktop.App)
- Microsoft.DotNet.Wpf.ProjectTemplates - 3.0.0 (parent: Microsoft.WindowsDesktop.App)
* Add a dependency on Microsoft.NETCore.Platforms
This is not directly depended upon, but causes Maestro to flow stable feed locations.
* Use runtime package version
* Fix installer download locations
* Update windows desktop installer location
* Explicit reference the host model
* Make ref package version explicit
* Update property used to identify host version
* Update apphost versions
* Updated property versions to be used for branding, crossgen and bundled versions generation.
* Use 3.0-preview7 when targeting netcoreapp3.0 with 5.0 SDK for now
* Update known app host packs and framework references to 5.0
* Remove workaround for fixed bug from tests
* Temporarily expect run failure while templates are still at 3.0
Moved templates folder under dotnet to Templates (capital T) and added dotnet/Templates to the deb installer.
Adding Templates to the sdk rpm native installer.
This commit marks the `Microsoft.WindowsDesktop.App` known framework reference
as Windows only. This will be used by a upcoming SDK change to ensure that
"Windows only" frameworks can only be used on Windows.
* Resolve named CAB collision; drop the CABs.
* Resolving naming convention warning: 8 chars plus {0} are allowed.
* Update src/redist/targets/packaging/windows/clisdk/dotnet.wxs
Co-Authored-By: Peter Huene <pehuene@microsoft.com>
This will be used by the SDK to locate the dotnet host when running in
desktop msbuild. Necessary for tools that always run on .NET Core,
like the IL Linker.
* Update dependencies from https://github.com/dotnet/toolset build 20190304.4
This change updates the following dependencies
- Microsoft.Dotnet.Toolset.Internal - 3.0.100-preview3.19154.4
* Pull toolset from new location
React to deprecation of Microsoft.AspNetCore.App.
Changes:
* Update KnownFrameworkReference to use the new runtime packs
* Stop reference Microsoft.AspNetCore.App
* Stop generating unused variable in the SDK: BundledAspNetCoreAppPackageVersion and BundledAspNetCoreAppTargetFrameworkVersion
* Add prodcon entries for all aspnet dependencies. These may not have the same version in the future (like patch updates)
* Update dependencies from https://github.com/dotnet/toolset build 20190219.13
This change updates the following dependencies
- Microsoft.Dotnet.Toolset.Internal - 3.0.100-preview3.19119.13
* Update dependencies from https://github.com/dotnet/toolset build 20190219.15
This change updates the following dependencies
- Microsoft.Dotnet.Toolset.Internal - 3.0.100-preview3.19119.15
* Update dependencies from https://github.com/dotnet/toolset build 20190219.16
This change updates the following dependencies
- Microsoft.Dotnet.Toolset.Internal - 3.0.100-preview3.19119.16
* In test projects, append to RestoreAdditionalProjectSources instead of replacing it
9ffae2ef94
* Don't crossgen reference assemblies redisted with msbuild for RoslynCodeTaskFactory
* Don't try to chmod RunFsc.sh that no longer exists
Also clean up a bunch of issues with the generatenupkg script:
* Output from nuget pack was getting lost
* Non-existent file was imported
* Literal '-ForegroundColor Green' was printed to the screen (didn't actually change the color)
* nuget.exe was being put inside the src/ tree, moved to artifacts/Tools/nuget
* Temporary nuspec was created unnecessarily, now use -Properties instead of search and replace
* Downgraded to nuget 3.5.0 to workaround a perf issue in nuget 4.x pack
* master:
Adding a Wpf and Winforms templates registry key (#218)
Update coresetup to preview-27218-01 (#216)
Update WindowsDesktop Framework (#215)
Update coresetup to preview-27217-02 (#214)
Update coresetup to preview-27217-01
Update coresetup to preview-27216-02 (#211)
make GivenDotnetUsesDotnetTools test optional based on AspNetCore availability (#207)
Update DependencyVersions.props
Include the WindowsDesktop sharedframework in install 'Finish' page. (#208)
Update readme; core-sdk:master (#209)
Update WindowsDesktop
Update toolset
Update coresetup to preview-27214-02
change debug to Debug to match managed part
add entry for freebsd to badge processing
update stage0 sdk to 3.0 preview
Update coresetup to preview-27206-02 (#202)
initial support for freebsd
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.
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.
