- 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.
