mirrors/dotnet-installer
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions
dotnet-installer/src/redist/targets/GenerateLayout.targets

526 lines
36 KiB
Text
Raw Normal View History

Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
<Project>
Move layout folder
2018-10-29 19:26:31 +00:00
<PropertyGroup>
<RedistLayoutPath>$(BaseOutputPath)$(Configuration)\dotnet\</RedistLayoutPath>
Generate Windows installers
2018-10-31 20:56:32 +00:00
<SdkInternalLayoutPath>$(BaseOutputPath)$(Configuration)\dotnet-internal\</SdkInternalLayoutPath>
Add 3.1 templates
2019-09-20 22:20:01 +00:00
<Templates31LayoutPath>$(BaseOutputPath)$(Configuration)\templates-3.1\</Templates31LayoutPath>
Adding 2.1 and 2.2 Templates MSIs, part 1
2019-07-17 23:18:41 +00:00
<Templates30LayoutPath>$(BaseOutputPath)$(Configuration)\templates-3.0\</Templates30LayoutPath>
<Templates22LayoutPath>$(BaseOutputPath)$(Configuration)\templates-2.2\</Templates22LayoutPath>
<Templates21LayoutPath>$(BaseOutputPath)$(Configuration)\templates-2.1\</Templates21LayoutPath>
Produce deb packages
2018-11-02 06:15:59 +00:00
<DownloadsFolder>$(IntermediateOutputPath)downloads\</DownloadsFolder>
Move layout folder
2018-10-29 19:26:31 +00:00
</PropertyGroup>
[release/3.0.1xx] Update dependencies from aspnet/AspNetCore (#4851) * Update dependencies from https://github.com/aspnet/AspNetCore build 20190915.2 - dotnet-user-secrets - 3.0.0-rc2.19465.2 - dotnet-watch - 3.0.0-rc2.19465.2 - Microsoft.AspNetCore.App.Ref - 3.0.0 - Microsoft.AspNetCore.App.Runtime.win-x64 - 3.0.0 - dotnet-dev-certs - 3.0.0-rc2.19465.2 - Microsoft.AspNetCore.DeveloperCertificates.XPlat - 3.0.0-rc2.19465.2 * Correctly identify aspnetcore blob subdir
2019-09-16 00:27:29 +00:00
<PropertyGroup>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<!-- Blob storage directories are not stabilized, so these must refer to a package that does not stabilize -->
<AspNetCoreBlobVersion>$(MicrosoftAspNetCoreDeveloperCertificatesXPlatPackageVersion)</AspNetCoreBlobVersion>
<CoreSetupBlobVersion>$(MicrosoftNETCoreAppInternalPackageVersion)</CoreSetupBlobVersion>
Merge branch 'release/3.1.1xx' into merges/release/3.0.1xx-to-release/3.1.1xx
2019-10-18 23:19:05 +00:00
<!-- Change these individually to or $(CoreSetupBlobVersion), $(AspNetCoreBlobVersion), or appropriate fixed version depending if corresponding .Ref packages are unpinned. -->
<NETCoreAppTargetingPackBlobVersion>$(CoreSetupBlobVersion)</NETCoreAppTargetingPackBlobVersion>
Fix build
2019-10-19 01:11:18 +00:00
<AspNetCoreTargetingPackBlobVersion>$(AspNetCoreBlobVersion)</AspNetCoreTargetingPackBlobVersion>
Fix merge issues
2019-10-19 00:12:15 +00:00
<WindowsDesktopTargetingPackBlobVersion>$(CoreSetupBlobVersion)</WindowsDesktopTargetingPackBlobVersion>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<NETStandardTargetingPackBlobVersion>3.0.0</NETStandardTargetingPackBlobVersion>
[release/3.0.1xx] Update dependencies from aspnet/AspNetCore (#4851) * Update dependencies from https://github.com/aspnet/AspNetCore build 20190915.2 - dotnet-user-secrets - 3.0.0-rc2.19465.2 - dotnet-watch - 3.0.0-rc2.19465.2 - Microsoft.AspNetCore.App.Ref - 3.0.0 - Microsoft.AspNetCore.App.Runtime.win-x64 - 3.0.0 - dotnet-dev-certs - 3.0.0-rc2.19465.2 - Microsoft.AspNetCore.DeveloperCertificates.XPlat - 3.0.0-rc2.19465.2 * Correctly identify aspnetcore blob subdir
2019-09-16 00:27:29 +00:00
</PropertyGroup>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
Generate Windows installers
2018-10-31 20:56:32 +00:00
<Target Name="SetupBundledComponents" DependsOnTargets="GetCurrentRuntimeInformation;SetupFileExtensions;SetSdkVersionInfo;SetBuildDefaults">
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
<PropertyGroup>
Include templates in layout
2018-11-12 23:23:44 +00:00
<SdkOutputDirectory>$(RedistLayoutPath)sdk\$(SdkVersion)\</SdkOutputDirectory>
Download blobs from MSRC storage & Add CredProvider to Dockerfiles (#4753) * 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
2019-10-01 20:22:33 +00:00
<InternalBuild Condition="$(SYSTEM_TEAMPROJECT) == 'internal' and $(BUILD_SOURCEBRANCH.ToLower().contains('internal'))">true</InternalBuild>
<CoreSetupBlobAccessTokenParam Condition="'$(InternalBuild)' == 'true'">$(DOTNETCLIMSRC_READ_SAS_TOKEN)</CoreSetupBlobAccessTokenParam>
<CoreSetupBlobRootUrl Condition="'$(CoreSetupBlobRootUrl)' == '' and '$(InternalBuild)' == 'true'">https://dotnetclimsrc.blob.core.windows.net/dotnet/</CoreSetupBlobRootUrl>
Don't reset blob URL if we pass it in.
2019-02-02 22:34:04 +00:00
<CoreSetupBlobRootUrl Condition="'$(CoreSetupBlobRootUrl)' == ''">https://dotnetcli.azureedge.net/dotnet/</CoreSetupBlobRootUrl>
Download blobs from MSRC storage & Add CredProvider to Dockerfiles (#4753) * 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
2019-10-01 20:22:33 +00:00
<DotnetExtensionsBlobRootUrl Condition="'$(DotnetExtensionsBlobRootUrl)' == '' and '$(InternalBuild)' == 'true'">https://dotnetclimsrc.blob.core.windows.net/dotnet/</DotnetExtensionsBlobRootUrl>
Don't reset blob URL if we pass it in.
2019-02-02 22:34:04 +00:00
<DotnetExtensionsBlobRootUrl Condition="'$(DotnetExtensionsBlobRootUrl)' == ''">https://dotnetcli.blob.core.windows.net/dotnet/</DotnetExtensionsBlobRootUrl>
Download blobs from MSRC storage & Add CredProvider to Dockerfiles (#4753) * 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
2019-10-01 20:22:33 +00:00
<DotnetToolsetBlobRootUrl Condition="'$(DotnetToolsetBlobRootUrl)' == '' and '$(InternalBuild)' == 'true'">https://dotnetclimsrc.blob.core.windows.net/dotnet/</DotnetToolsetBlobRootUrl>
[release/3.0.1xx] Update dependencies from dotnet/toolset (#824) * 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
2019-03-04 17:03:03 +00:00
<DotnetToolsetBlobRootUrl Condition="'$(DotnetToolsetBlobRootUrl)' == ''">https://dotnetfeed.blob.core.windows.net/dotnet-toolset/</DotnetToolsetBlobRootUrl>
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Allow specifying CoreSetupRid.
2019-03-10 05:21:04 +00:00
<CoreSetupRid Condition="'$(CoreSetupRid)' == ''">$(HostRid)</CoreSetupRid>
Fixing FreeBSD build.
2018-12-28 23:08:05 +00:00
<CoreSetupRid Condition=" ('$(HostOSName)' == 'win' or '$(HostOSName)' == 'osx' or '$(HostOSName)' == 'freebsd') and '$(DotNetBuildFromSource)' != 'true' ">$(HostMonikerRid)</CoreSetupRid>
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
<!-- only the runtime OSX .pkgs have a `-internal` suffix -->
<InstallerStartSuffix Condition="'$(HostOSName)' == 'osx'">-internal</InstallerStartSuffix>
<!-- Downloaded Installers + Archives -->
<!-- Use the "x64" Rid when downloading Linux shared framework 'DEB' installer files. -->
<SharedFrameworkInstallerFileRid>$(CoreSetupRid)</SharedFrameworkInstallerFileRid>
<SharedFrameworkInstallerFileRid Condition=" '$(IsDebianBaseDistro)' == 'true' OR '$(IsRPMBasedDistro)' == 'true' ">x64</SharedFrameworkInstallerFileRid>
Download consolidated dotnet-runtime-deps Deb pkg
2019-05-03 22:18:14 +00:00
<!-- Use the "x64" Rid when downloading Linux runtime dependencies Debian package. -->
<RuntimeDepsInstallerFileRid>$(CoreSetupRid)</RuntimeDepsInstallerFileRid>
<RuntimeDepsInstallerFileRid Condition=" '$(IsDebianBaseDistro)' == 'true' ">x64</RuntimeDepsInstallerFileRid>
Add CrossPlatform AppHost Packs; release/3.1.1xx (#4916) * Add CrossPlatform AppHost Packs for arm & arm64.
2019-09-24 17:36:04 +00:00
<AlternateArchitecture Condition="'$(Architecture)' == 'x86'">x64</AlternateArchitecture>
<AlternateArchitecture Condition="'$(Architecture)' == 'x64'">x86</AlternateArchitecture>
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
<DownloadedSharedHostInstallerFileName Condition=" '$(InstallerExtension)' != '' ">dotnet-host$(InstallerStartSuffix)-$(SharedHostVersion)-$(SharedFrameworkInstallerFileRid)$(InstallerExtension)</DownloadedSharedHostInstallerFileName>
<DownloadedHostFxrInstallerFileName Condition=" '$(InstallerExtension)' != '' ">dotnet-hostfxr$(InstallerStartSuffix)-$(HostFxrVersion)-$(SharedFrameworkInstallerFileRid)$(InstallerExtension)</DownloadedHostFxrInstallerFileName>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<DownloadedSharedFrameworkInstallerFileName Condition=" '$(InstallerExtension)' != '' ">dotnet-runtime$(InstallerStartSuffix)-$(MicrosoftNETCoreAppRuntimePackageVersion)-$(SharedFrameworkInstallerFileRid)$(InstallerExtension)</DownloadedSharedFrameworkInstallerFileName>
Download consolidated dotnet-runtime-deps Deb pkg
2019-05-03 22:18:14 +00:00
<DownloadedRuntimeDepsInstallerFileName Condition=" '$(InstallerExtension)' != '' ">dotnet-runtime-deps-$(SharedHostVersion)-$(RuntimeDepsInstallerFileRid)$(InstallerExtension)</DownloadedRuntimeDepsInstallerFileName>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<DownloadedWinFormsAndWpfSharedFrameworkInstallerFileName Condition=" '$(InstallerExtension)' != '' ">windowsdesktop-runtime-$(MicrosoftWindowsDesktopAppRuntimePackageVersion)-$(SharedFrameworkInstallerFileRid)$(InstallerExtension)</DownloadedWinFormsAndWpfSharedFrameworkInstallerFileName>
<DownloadedNetCoreAppTargetingPackInstallerFileName Condition=" '$(InstallerExtension)' != '' ">dotnet-targeting-pack-$(MicrosoftNETCoreAppRefPackageVersion)-$(SharedFrameworkInstallerFileRid)$(InstallerExtension)</DownloadedNetCoreAppTargetingPackInstallerFileName>
<DownloadedNetCoreAppHostPackInstallerFileName Condition=" '$(InstallerExtension)' != '' ">dotnet-apphost-pack-$(MicrosoftNETCoreAppHostPackageVersion)-$(SharedFrameworkInstallerFileRid)$(InstallerExtension)</DownloadedNetCoreAppHostPackInstallerFileName>
Fix merge issues
2019-10-19 00:12:15 +00:00
<DownloadedAlternateNetCoreAppHostPackInstallerFileName Condition=" '$(InstallerExtension)' != '' ">dotnet-apphost-pack-$(MicrosoftNETCoreAppHostPackageVersion)-$(SharedFrameworkInstallerFileRid)_$(AlternateArchitecture)$(InstallerExtension)</DownloadedAlternateNetCoreAppHostPackInstallerFileName>
<DownloadedArmNetCoreAppHostPackInstallerFileName Condition=" '$(InstallerExtension)' != '' ">dotnet-apphost-pack-$(MicrosoftNETCoreAppHostPackageVersion)-$(SharedFrameworkInstallerFileRid)_arm$(InstallerExtension)</DownloadedArmNetCoreAppHostPackInstallerFileName>
<DownloadedArm64NetCoreAppHostPackInstallerFileName Condition=" '$(InstallerExtension)' != '' ">dotnet-apphost-pack-$(MicrosoftNETCoreAppHostPackageVersion)-$(SharedFrameworkInstallerFileRid)_arm64$(InstallerExtension)</DownloadedArm64NetCoreAppHostPackInstallerFileName>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<DownloadedWindowsDesktopTargetingPackInstallerFileName Condition=" '$(InstallerExtension)' != '' ">windowsdesktop-targeting-pack-$(MicrosoftWindowsDesktopAppRefPackageVersion)-$(SharedFrameworkInstallerFileRid)$(InstallerExtension)</DownloadedWindowsDesktopTargetingPackInstallerFileName>
adding .Net standard 2.1 Targeting Packs (#1309) * adding .Net standard 2.1 Targeting Packs
2019-04-10 15:55:46 +00:00
<DownloadedNetStandardTargetingPackInstallerFileName Condition=" '$(InstallerExtension)' != '' ">netstandard-targeting-pack-$(NETStandardLibraryRefPackageVersion)-$(SharedFrameworkInstallerFileRid)$(InstallerExtension)</DownloadedNetStandardTargetingPackInstallerFileName>
<NetStandardTargetingPackTargetFramework>netstandard$(NETStandardLibraryRefPackageVersion.Split('.')[0])$(NETStandardLibraryRefPackageVersion.Split('.')[1])</NetStandardTargetingPackTargetFramework>
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
<!-- Use the portable "linux-x64" Rid when downloading Linux shared framework compressed file. -->
<SharedFrameworkRid>$(CoreSetupRid)</SharedFrameworkRid>
<SharedFrameworkRid Condition=" '$(ProductMonikerRid)' == 'linux-musl-x64' ">$(ProductMonikerRid)</SharedFrameworkRid>
<SharedFrameworkRid Condition=" '$(UsePortableLinuxSharedFramework)' == 'true' ">linux-$(Architecture)</SharedFrameworkRid>
Merge branch 'release/3.1.1xx' into merges/release/3.0.1xx-to-release/3.1.1xx
2019-10-18 23:19:05 +00:00
<CombinedFrameworkHostArchiveFileName>dotnet-runtime-$(MicrosoftNETCoreAppRuntimePackageVersion)-$(SharedFrameworkRid)$(ArchiveExtension)</CombinedFrameworkHostArchiveFileName>
Fix merge issues
2019-10-19 00:12:15 +00:00
<WinFormsAndWpfSharedFxArchiveFileName>windowsdesktop-runtime-$(MicrosoftWindowsDesktopAppRuntimePackageVersion)-$(SharedFrameworkRid)$(ArchiveExtension)</WinFormsAndWpfSharedFxArchiveFileName>
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
Don't overwrite AspNetCoreSharedFxInstallerRid if it's already set. (#4734)
2019-09-11 22:45:08 +00:00
<AspNetCoreSharedFxInstallerRid Condition="'$(AspNetCoreSharedFxInstallerRid)' == ''">$(SharedFrameworkRid)</AspNetCoreSharedFxInstallerRid>
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
<AspNetCoreSharedFxInstallerRid Condition="'$(SharedFrameworkRid)' == 'rhel.6-x64'">linux-x64</AspNetCoreSharedFxInstallerRid>
<AspNetCoreSharedFxArchiveRid>$(AspNetCoreSharedFxInstallerRid)</AspNetCoreSharedFxArchiveRid>
<AspNetCoreSharedFxInstallerRid Condition="'$(InstallerExtension)' == '.deb' OR '$(InstallerExtension)' == '.rpm'">x64</AspNetCoreSharedFxInstallerRid>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<DownloadedAspNetCoreSharedFxInstallerFileName Condition=" '$(InstallerExtension)' != '' AND '$(HostOSName)' != 'osx' ">aspnetcore-runtime-$(MicrosoftAspNetCoreAppRuntimePackageVersion)-$(AspNetCoreSharedFxInstallerRid)$(InstallerExtension)</DownloadedAspNetCoreSharedFxInstallerFileName>
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
<!-- Note: we use the "-internal" archives and installers that contain only the aspnetcore shared framework, and shouldn't overlap with Microsoft.NETCore.App. -->
Merge branch 'release/3.1.1xx' into merges/release/3.0.1xx-to-release/3.1.1xx
2019-10-18 23:19:05 +00:00
<DownloadedAspNetCoreSharedFxWixLibFileName Condition=" '$(InstallerExtension)' == '.msi' ">aspnetcore-runtime-internal-$(MicrosoftAspNetCoreAppRuntimePackageVersion)-$(AspNetCoreSharedFxInstallerRid).wixlib</DownloadedAspNetCoreSharedFxWixLibFileName>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<DownloadedAspNetTargetingPackInstallerFileName Condition=" '$(InstallerExtension)' != '' ">aspnetcore-targeting-pack-$(MicrosoftAspNetCoreAppRefPackageVersion)$(InstallerExtension)</DownloadedAspNetTargetingPackInstallerFileName>
<DownloadedAspNetTargetingPackInstallerFileName Condition=" '$(InstallerExtension)' == '.msi' ">aspnetcore-targeting-pack-$(MicrosoftAspNetCoreAppRefPackageVersion)-$(AspNetCoreSharedFxInstallerRid)$(InstallerExtension)</DownloadedAspNetTargetingPackInstallerFileName>
Fix merge issues
2019-10-19 00:12:15 +00:00
<DownloadedAspNetCoreV2ModuleInstallerFileName Condition=" '$(InstallerExtension)' == '.msi' ">aspnetcoremodule_$(Architecture)_en_v2_$(MicrosoftAspNetCoreAppRuntimePackageVersion)$(InstallerExtension)</DownloadedAspNetCoreV2ModuleInstallerFileName>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<AspNetTargetingPackArchiveFileName>aspnetcore-targeting-pack-$(MicrosoftAspNetCoreAppRefPackageVersion)$(ArchiveExtension)</AspNetTargetingPackArchiveFileName>
<AspNetCoreSharedFxArchiveFileName>aspnetcore-runtime-internal-$(MicrosoftAspNetCoreAppRuntimePackageVersion)-$(AspNetCoreSharedFxArchiveRid)$(ArchiveExtension)</AspNetCoreSharedFxArchiveFileName>
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
<!-- Used to detect if ASP.NET Core is built against the same version of Microsoft.NETCore.App. -->
<AspNetCoreSharedFxBaseRuntimeVersionFileName>aspnetcore_base_runtime.version</AspNetCoreSharedFxBaseRuntimeVersionFileName>
</PropertyGroup>
<PropertyGroup>
<CoreSetupRootUrl>$(CoreSetupBlobRootUrl)Runtime/</CoreSetupRootUrl>
<AspNetCoreSharedFxRootUrl>$(CoreSetupBlobRootUrl)aspnetcore/Runtime/</AspNetCoreSharedFxRootUrl>
[master] Update dependencies from dotnet/core-setup (#1447) * Update dependencies from https://github.com/dotnet/core-setup build 20190412.04 - Microsoft.NETCore.App - 3.0.0-preview5-27612-04 - Microsoft.WindowsDesktop.App - 3.0.0-preview5-27612-04 - NETStandard.Library.Ref - 2.1.0-preview5-27612-04 * Update dependencies from https://github.com/dotnet/core-setup build 20190412.06 - Microsoft.NETCore.App - 3.0.0-preview5-27612-06 - Microsoft.WindowsDesktop.App - 3.0.0-preview5-27612-06 - NETStandard.Library.Ref - 2.1.0-preview5-27612-06 * Updating 'windowsdesktop-runtime' asset names and blob paths. * Updating the blob root... * Updating the RID for 'windowsdesktop-runtime' archive.
2019-04-12 20:15:30 +00:00
<WinFormsAndWpfSharedFxRootUrl>$(CoreSetupRootUrl)</WinFormsAndWpfSharedFxRootUrl>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<CoreSetupDownloadDirectory>$(IntermediateDirectory)/coreSetupDownload/$(MicrosoftNETCoreAppRuntimePackageVersion)</CoreSetupDownloadDirectory>
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
<CombinedSharedHostAndFrameworkArchive>$(CoreSetupDownloadDirectory)/combinedSharedHostAndFrameworkArchive$(ArchiveExtension)</CombinedSharedHostAndFrameworkArchive>
</PropertyGroup>
Use WindowsDesktop.App.*Ref*, add more packs to .zip (#698)
2019-02-26 19:09:56 +00:00
Add CrossPlatform AppHost Packs; release/3.1.1xx (#4916) * Add CrossPlatform AppHost Packs for arm & arm64.
2019-09-24 17:36:04 +00:00
<PropertyGroup Condition="'$(HostOSName)' == 'win' And !$(Architecture.StartsWith('arm'))">
<AlternateAppHostRid>win-$(AlternateArchitecture)</AlternateAppHostRid>
<ArmAppHostRid>win-arm</ArmAppHostRid>
<Arm64AppHostRid>win-arm64</Arm64AppHostRid>
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
</PropertyGroup>
adding .Net core AppHost pack (#1519) * adding .Net core AppHost pack
2019-04-17 19:53:05 +00:00
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
<ItemGroup>
<BundledLayoutComponent Include="CombinedSharedHostAndFrameworkArchive">
Download shared runtime archive from correct blob location (#5308)
2019-10-25 20:54:21 +00:00
<BaseUrl>$(CoreSetupRootUrl)$(CoreSetupBlobVersion)</BaseUrl>
Download the ASP.NET SharedFramework MSI and the Module V2 MSI
2019-09-09 19:38:32 +00:00
<DownloadFileName>$(CombinedFrameworkHostArchiveFileName)</DownloadFileName>
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
<RelativeLayoutPath></RelativeLayoutPath>
</BundledLayoutComponent>
Add more components to download / layout
2018-10-24 07:08:51 +00:00
Use .Ref targeting packs and include in layout under packs folder
2019-02-20 15:30:40 +00:00
<BundledLayoutPackage Include="MicrosoftNetCoreAppTargetingPackNupkg">
<PackageName>Microsoft.NETCore.App.Ref</PackageName>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<PackageVersion>$(MicrosoftNETCoreAppRefPackageVersion)</PackageVersion>
adding .Net standard 2.1 Targeting Packs (#1309) * adding .Net standard 2.1 Targeting Packs
2019-04-10 15:55:46 +00:00
<TargetFramework>$(TargetFramework)</TargetFramework>
Use .Ref targeting packs and include in layout under packs folder
2019-02-20 15:30:40 +00:00
<RelativeLayoutPath>packs/%(PackageName)/%(PackageVersion)</RelativeLayoutPath>
</BundledLayoutPackage>
adding .Net standard 2.1 Targeting Packs (#1309) * adding .Net standard 2.1 Targeting Packs
2019-04-10 15:55:46 +00:00
<BundledLayoutPackage Include="MicrosoftNetStandardTargetingPackNupkg">
<PackageName>NETStandard.Library.Ref</PackageName>
<PackageVersion>$(NETStandardLibraryRefPackageVersion)</PackageVersion>
<TargetFramework>$(NetStandardTargetingPackTargetFramework)</TargetFramework>
<RelativeLayoutPath>packs/%(PackageName)/%(PackageVersion)</RelativeLayoutPath>
</BundledLayoutPackage>
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Use .Ref targeting packs and include in layout under packs folder
2019-02-20 15:30:40 +00:00
<BundledLayoutPackage Include="MicrosoftAspNetCoreAppTargetingPackNupkg">
<PackageName>Microsoft.AspNetCore.App.Ref</PackageName>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<PackageVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</PackageVersion>
adding .Net standard 2.1 Targeting Packs (#1309) * adding .Net standard 2.1 Targeting Packs
2019-04-10 15:55:46 +00:00
<TargetFramework>$(TargetFramework)</TargetFramework>
Use .Ref targeting packs and include in layout under packs folder
2019-02-20 15:30:40 +00:00
<RelativeLayoutPath>packs/%(PackageName)/%(PackageVersion)</RelativeLayoutPath>
</BundledLayoutPackage>
Use WindowsDesktop.App.*Ref*, add more packs to .zip (#698)
2019-02-26 19:09:56 +00:00
<BundledLayoutPackage Include="MicrosoftNetCoreAppHostPackNupkg">
adding .Net core AppHost pack (#1519) * adding .Net core AppHost pack
2019-04-17 19:53:05 +00:00
<PackageName>Microsoft.NETCore.App.Host.$(SharedFrameworkRid)</PackageName>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<PackageVersion>$(MicrosoftNETCoreAppHostPackageVersion)</PackageVersion>
adding .Net standard 2.1 Targeting Packs (#1309) * adding .Net standard 2.1 Targeting Packs
2019-04-10 15:55:46 +00:00
<TargetFramework>$(TargetFramework)</TargetFramework>
Use WindowsDesktop.App.*Ref*, add more packs to .zip (#698)
2019-02-26 19:09:56 +00:00
<RelativeLayoutPath>packs/%(PackageName)/%(PackageVersion)</RelativeLayoutPath>
</BundledLayoutPackage>
adding .Net core AppHost pack (#1519) * adding .Net core AppHost pack
2019-04-17 19:53:05 +00:00
<BundledLayoutPackage Include="MicrosoftNetCoreAppHostPackNupkg_Alternate" Condition="'$(AlternateAppHostRid)' != ''">
<PackageName>Microsoft.NETCore.App.Host.$(AlternateAppHostRid)</PackageName>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<PackageVersion>$(MicrosoftNETCoreAppHostPackageVersion)</PackageVersion>
adding .Net standard 2.1 Targeting Packs (#1309) * adding .Net standard 2.1 Targeting Packs
2019-04-10 15:55:46 +00:00
<TargetFramework>$(TargetFramework)</TargetFramework>
Use WindowsDesktop.App.*Ref*, add more packs to .zip (#698)
2019-02-26 19:09:56 +00:00
<RelativeLayoutPath>packs/%(PackageName)/%(PackageVersion)</RelativeLayoutPath>
</BundledLayoutPackage>
Add CrossPlatform AppHost Packs; release/3.1.1xx (#4916) * Add CrossPlatform AppHost Packs for arm & arm64.
2019-09-24 17:36:04 +00:00
<BundledLayoutPackage Include="MicrosoftNetCoreAppHostPackNupkg_Arm" Condition="'$(ArmAppHostRid)' != ''">
<PackageName>Microsoft.NETCore.App.Host.$(ArmAppHostRid)</PackageName>
Fix merge issues
2019-10-19 00:12:15 +00:00
<PackageVersion>$(MicrosoftNETCoreAppHostPackageVersion)</PackageVersion>
Add CrossPlatform AppHost Packs; release/3.1.1xx (#4916) * Add CrossPlatform AppHost Packs for arm & arm64.
2019-09-24 17:36:04 +00:00
<TargetFramework>$(TargetFramework)</TargetFramework>
<RelativeLayoutPath>packs/%(PackageName)/%(PackageVersion)</RelativeLayoutPath>
</BundledLayoutPackage>
<BundledLayoutPackage Include="MicrosoftNetCoreAppHostPackNupkg_Arm64" Condition="'$(Arm64AppHostRid)' != ''">
<PackageName>Microsoft.NETCore.App.Host.$(Arm64AppHostRid)</PackageName>
Fix merge issues
2019-10-19 00:12:15 +00:00
<PackageVersion>$(MicrosoftNETCoreAppHostPackageVersion)</PackageVersion>
Add CrossPlatform AppHost Packs; release/3.1.1xx (#4916) * Add CrossPlatform AppHost Packs for arm & arm64.
2019-09-24 17:36:04 +00:00
<TargetFramework>$(TargetFramework)</TargetFramework>
<RelativeLayoutPath>packs/%(PackageName)/%(PackageVersion)</RelativeLayoutPath>
</BundledLayoutPackage>
Add more components to download / layout
2018-10-24 07:08:51 +00:00
<BundledInstallerComponent Include="DownloadedRuntimeDepsInstallerFile"
Condition="('$(IsDebianBaseDistro)' == 'true' OR '$(IsRPMBasedDistro)' == 'true') And '$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' != '' And !$(Architecture.StartsWith('arm'))">
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<BaseUrl>$(CoreSetupRootUrl)$(CoreSetupBlobVersion)</BaseUrl>
Add more components to download / layout
2018-10-24 07:08:51 +00:00
<DownloadFileName>$(DownloadedRuntimeDepsInstallerFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
</BundledInstallerComponent>
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Add more components to download / layout
2018-10-24 07:08:51 +00:00
<BundledInstallerComponent Include="DownloadedSharedFrameworkInstallerFile"
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' != '' And !$(Architecture.StartsWith('arm'))">
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<BaseUrl>$(CoreSetupRootUrl)$(CoreSetupBlobVersion)</BaseUrl>
Add more components to download / layout
2018-10-24 07:08:51 +00:00
<DownloadFileName>$(DownloadedSharedFrameworkInstallerFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
</BundledInstallerComponent>
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Add more components to download / layout
2018-10-24 07:08:51 +00:00
<BundledInstallerComponent Include="DownloadedSharedHostInstallerFile"
Include the targeting pack MSI in the SDK bundle installation (#588) * Include the targeting pack MSI in the SDK bundle installation.
2019-02-21 00:36:11 +00:00
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' != '' And !$(Architecture.StartsWith('arm'))">
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<BaseUrl>$(CoreSetupRootUrl)$(CoreSetupBlobVersion)</BaseUrl>
Add more components to download / layout
2018-10-24 07:08:51 +00:00
<DownloadFileName>$(DownloadedSharedHostInstallerFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
</BundledInstallerComponent>
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Add more components to download / layout
2018-10-24 07:08:51 +00:00
<BundledInstallerComponent Include="DownloadedHostFxrInstallerFile"
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' != '' And !$(Architecture.StartsWith('arm'))">
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<BaseUrl>$(CoreSetupRootUrl)$(CoreSetupBlobVersion)</BaseUrl>
Add more components to download / layout
2018-10-24 07:08:51 +00:00
<DownloadFileName>$(DownloadedHostFxrInstallerFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
</BundledInstallerComponent>
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Include the targeting pack MSI in the SDK bundle installation (#588) * Include the targeting pack MSI in the SDK bundle installation.
2019-02-21 00:36:11 +00:00
<BundledInstallerComponent Include="DownloadedNetCoreAppTargetingPackInstallerFile"
Linux native installer updates: DEB and RPM (#1122) Adding targeting packs to native Linux installers. * Re-enable RPM and DEB installation testing.
2019-04-01 21:24:56 +00:00
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' != '' And !$(Architecture.StartsWith('arm'))">
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<BaseUrl>$(CoreSetupRootUrl)$(NETCoreAppTargetingPackBlobVersion)</BaseUrl>
Include the targeting pack MSI in the SDK bundle installation (#588) * Include the targeting pack MSI in the SDK bundle installation.
2019-02-21 00:36:11 +00:00
<DownloadFileName>$(DownloadedNetCoreAppTargetingPackInstallerFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
</BundledInstallerComponent>
Include the WindowsDesktop targeting pack MSI in the SDK bundle installation. (#1062)
2019-03-19 21:15:32 +00:00
adding .Net standard 2.1 Targeting Packs (#1309) * adding .Net standard 2.1 Targeting Packs
2019-04-10 15:55:46 +00:00
<BundledInstallerComponent Include="DownloadedNetStandardTargetingPackInstallerFile"
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' != '' And !$(Architecture.StartsWith('arm'))">
Merge branch 'release/3.1.1xx' into merges/release/3.0.1xx-to-release/3.1.1xx
2019-10-18 23:19:05 +00:00
<BaseUrl>$(CoreSetupRootUrl)$(MicrosoftNETCoreAppRuntimewinx64PackageVersion)</BaseUrl>
Use stable 3.0.0/2.1.0 versions where appropriate
2019-09-24 19:48:28 +00:00
<BaseUrl>$(CoreSetupRootUrl)3.0.0</BaseUrl>
adding .Net standard 2.1 Targeting Packs (#1309) * adding .Net standard 2.1 Targeting Packs
2019-04-10 15:55:46 +00:00
<DownloadFileName>$(DownloadedNetStandardTargetingPackInstallerFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
</BundledInstallerComponent>
adding .Net core AppHost pack (#1519) * adding .Net core AppHost pack
2019-04-17 19:53:05 +00:00
<BundledInstallerComponent Include="DownloadedNetCoreAppHostPackInstallerFile"
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' != '' And !$(Architecture.StartsWith('arm'))">
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<BaseUrl>$(CoreSetupRootUrl)$(CoreSetupBlobVersion)</BaseUrl>
adding .Net core AppHost pack (#1519) * adding .Net core AppHost pack
2019-04-17 19:53:05 +00:00
<DownloadFileName>$(DownloadedNetCoreAppHostPackInstallerFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
</BundledInstallerComponent>
Add CrossPlatform AppHost Packs; release/3.1.1xx (#4916) * Add CrossPlatform AppHost Packs for arm & arm64.
2019-09-24 17:36:04 +00:00
<BundledInstallerComponent Include="DownloadedAlternateNetCoreAppHostPackInstallerFile"
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' == '.msi' And !$(Architecture.StartsWith('arm'))">
Fix merge issues
2019-10-19 00:12:15 +00:00
<BaseUrl>$(CoreSetupRootUrl)$(CoreSetupBlobVersion)</BaseUrl>
Add CrossPlatform AppHost Packs; release/3.1.1xx (#4916) * Add CrossPlatform AppHost Packs for arm & arm64.
2019-09-24 17:36:04 +00:00
<DownloadFileName>$(DownloadedAlternateNetCoreAppHostPackInstallerFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
</BundledInstallerComponent>
<BundledInstallerComponent Include="DownloadedArmNetCoreAppHostPackInstallerFile"
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' == '.msi' And !$(Architecture.StartsWith('arm'))">
Fix merge issues
2019-10-19 00:12:15 +00:00
<BaseUrl>$(CoreSetupRootUrl)$(CoreSetupBlobVersion)</BaseUrl>
Add CrossPlatform AppHost Packs; release/3.1.1xx (#4916) * Add CrossPlatform AppHost Packs for arm & arm64.
2019-09-24 17:36:04 +00:00
<DownloadFileName>$(DownloadedArmNetCoreAppHostPackInstallerFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
</BundledInstallerComponent>
<BundledInstallerComponent Include="DownloadedArm64NetCoreAppHostPackInstallerFile"
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' == '.msi' And !$(Architecture.StartsWith('arm'))">
Fix merge issues
2019-10-19 00:12:15 +00:00
<BaseUrl>$(CoreSetupRootUrl)$(CoreSetupBlobVersion)</BaseUrl>
Add CrossPlatform AppHost Packs; release/3.1.1xx (#4916) * Add CrossPlatform AppHost Packs for arm & arm64.
2019-09-24 17:36:04 +00:00
<DownloadFileName>$(DownloadedArm64NetCoreAppHostPackInstallerFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
adding .Net core AppHost pack (#1519) * adding .Net core AppHost pack
2019-04-17 19:53:05 +00:00
</BundledInstallerComponent>
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Linux native installer updates: DEB and RPM (#1122) Adding targeting packs to native Linux installers. * Re-enable RPM and DEB installation testing.
2019-04-01 21:24:56 +00:00
<BundledInstallerComponent Include="DownloadedWindowsDesktopTargetingPackInstallerFile"
Include the WindowsDesktop targeting pack MSI in the SDK bundle installation. (#1062)
2019-03-19 21:15:32 +00:00
Condition="'$(InstallerExtension)' == '.msi' And '$(SkipBuildingInstallers)' != 'true' And !$(Architecture.StartsWith('arm'))">
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<BaseUrl>$(CoreSetupRootUrl)$(WindowsDesktopTargetingPackBlobVersion)</BaseUrl>
Include the WindowsDesktop targeting pack MSI in the SDK bundle installation. (#1062)
2019-03-19 21:15:32 +00:00
<DownloadFileName>$(DownloadedWindowsDesktopTargetingPackInstallerFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
</BundledInstallerComponent>
Include DesktopUI shared framework and toolset in redist layout
2018-10-24 23:05:02 +00:00
<BundledLayoutComponent Include="ToolsetArchive">
[release/3.0.1xx] Update dependencies from dotnet/toolset (#824) * 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
2019-03-04 17:03:03 +00:00
<BaseUrl>$(DotnetToolsetBlobRootUrl)Toolset/$(MicrosoftDotnetToolsetInternalPackageVersion)</BaseUrl>
Updating the property name for toolset dependency uptake based on the fake package being published there.
2019-01-15 23:37:37 +00:00
<DownloadFileName>dotnet-toolset-internal-$(MicrosoftDotnetToolsetInternalPackageVersion).zip</DownloadFileName>
Include DesktopUI shared framework and toolset in redist layout
2018-10-24 23:05:02 +00:00
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
<RelativeLayoutPath>sdk/$(SdkVersion)</RelativeLayoutPath>
</BundledLayoutComponent>
Add more components to download / layout
2018-10-24 07:08:51 +00:00
</ItemGroup>
Include the WindowsDesktop targeting pack MSI in the SDK bundle installation. (#1062)
2019-03-19 21:15:32 +00:00
Add more components to download / layout
2018-10-24 07:08:51 +00:00
<ItemGroup Condition=" '$(IncludeAspNetCoreRuntime)' != 'false' ">
Adding the NetCoreApp and ASP.Net Targeting Packs to the native MacOS installer (#1173) Adding the NetCoreApp and ASP.Net Targeting Packs to the native MacOS installer - PKG * Add the ASP.Net Targeting Pack from an archive.
2019-04-02 22:51:47 +00:00
<BundledLayoutComponent Include="DownloadedAspNetCoreSharedFxArchiveFile">
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<BaseUrl>$(AspNetCoreSharedFxRootUrl)$(AspNetCoreBlobVersion)</BaseUrl>
Add more components to download / layout
2018-10-24 07:08:51 +00:00
<DownloadFileName>$(AspNetCoreSharedFxArchiveFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
<RelativeLayoutPath></RelativeLayoutPath>
</BundledLayoutComponent>
Adding the NetCoreApp and ASP.Net Targeting Packs to the native MacOS installer (#1173) Adding the NetCoreApp and ASP.Net Targeting Packs to the native MacOS installer - PKG * Add the ASP.Net Targeting Pack from an archive.
2019-04-02 22:51:47 +00:00
<!-- The AspNet does not provide native MacOS PKG installers at this time; we use AspNet archives.
https://github.com/aspnet/AspNetCore/issues/8806 -->
<BundledLayoutComponent Include="DownloadedAspNetTargetingPackArchiveFile"
Condition="'$(InstallerExtension)' == '.pkg' And '$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' != '' And !$(Architecture.StartsWith('arm'))">
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<BaseUrl>$(AspNetCoreSharedFxRootUrl)$(AspNetCoreTargetingPackBlobVersion)</BaseUrl>
Adding the NetCoreApp and ASP.Net Targeting Packs to the native MacOS installer (#1173) Adding the NetCoreApp and ASP.Net Targeting Packs to the native MacOS installer - PKG * Add the ASP.Net Targeting Pack from an archive.
2019-04-02 22:51:47 +00:00
<DownloadFileName>$(AspNetTargetingPackArchiveFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
<RelativeLayoutPath></RelativeLayoutPath>
</BundledLayoutComponent>
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Include the targeting pack MSI in the SDK bundle installation (#588) * Include the targeting pack MSI in the SDK bundle installation.
2019-02-21 00:36:11 +00:00
<BundledInstallerComponent Include="DownloadedAspNetTargetingPackInstallerFile"
Linux native installer updates: DEB and RPM (#1122) Adding targeting packs to native Linux installers. * Re-enable RPM and DEB installation testing.
2019-04-01 21:24:56 +00:00
Condition="'$(InstallerExtension)' != '.pkg' And '$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' != '' And !$(Architecture.StartsWith('arm'))">
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<BaseUrl Condition="'$(AspNetTargetingPackIsPinned)' == 'true'">$(AspNetCoreSharedFxRootUrl)$(MicrosoftAspNetCoreAppRefPackageVersion)</BaseUrl>
<BaseUrl Condition="'$(AspNetTargetingPackIsPinned)' != 'true'">$(AspNetCoreSharedFxRootUrl)$(MicrosoftAspNetCoreAppRefPackageVersion)</BaseUrl>
Include the targeting pack MSI in the SDK bundle installation (#588) * Include the targeting pack MSI in the SDK bundle installation.
2019-02-21 00:36:11 +00:00
<DownloadFileName>$(DownloadedAspNetTargetingPackInstallerFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
</BundledInstallerComponent>
Include the WindowsDesktop targeting pack MSI in the SDK bundle installation. (#1062)
2019-03-19 21:15:32 +00:00
Add more components to download / layout
2018-10-24 07:08:51 +00:00
<BundledInstallerComponent Include="DownloadedAspNetCoreSharedFxInstallerFile"
Download the ASP.NET SharedFramework MSI and the Module V2 MSI
2019-09-09 19:38:32 +00:00
Condition="'$(InstallerExtension)' != '.pkg' And '$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' != '' And !$(Architecture.StartsWith('arm'))">
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<BaseUrl>$(AspNetCoreSharedFxRootUrl)$(AspNetCoreBlobVersion)</BaseUrl>
Add more components to download / layout
2018-10-24 07:08:51 +00:00
<DownloadFileName>$(DownloadedAspNetCoreSharedFxInstallerFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
</BundledInstallerComponent>
Download the ASP.NET SharedFramework MSI and the Module V2 MSI
2019-09-09 19:38:32 +00:00
<BundledInstallerComponent Include="DownloadedAspNetCoreSharedFxWixLibFile"
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' == '.msi' And !$(Architecture.StartsWith('arm'))">
Merge branch 'release/3.1.1xx' into merges/release/3.0.1xx-to-release/3.1.1xx
2019-10-18 23:19:05 +00:00
<BaseUrl>$(AspNetCoreSharedFxRootUrl)$(AspNetCoreBlobVersion)</BaseUrl>
Download the ASP.NET SharedFramework MSI and the Module V2 MSI
2019-09-09 19:38:32 +00:00
<DownloadFileName>$(DownloadedAspNetCoreSharedFxWixLibFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
</BundledInstallerComponent>
<BundledInstallerComponent Include="DownloadedAspNetCoreV2ModuleInstallerFile"
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' == '.msi' And !$(Architecture.StartsWith('arm'))">
Merge branch 'release/3.1.1xx' into merges/release/3.0.1xx-to-release/3.1.1xx
2019-10-18 23:19:05 +00:00
<BaseUrl>$(AspNetCoreSharedFxRootUrl)$(AspNetCoreBlobVersion)</BaseUrl>
Download the ASP.NET SharedFramework MSI and the Module V2 MSI
2019-09-09 19:38:32 +00:00
<DownloadFileName>$(DownloadedAspNetCoreV2ModuleInstallerFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
</BundledInstallerComponent>
Add more components to download / layout
2018-10-24 07:08:51 +00:00
<BundledInstallerComponent Include="AspNetCoreSharedFxBaseRuntimeVersionFile"
Condition="!$(Architecture.StartsWith('arm'))">
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<BaseUrl>$(AspNetCoreSharedFxRootUrl)$(AspNetCoreBlobVersion)</BaseUrl>
Add more components to download / layout
2018-10-24 07:08:51 +00:00
<DownloadFileName>$(AspNetCoreSharedFxBaseRuntimeVersionFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
</BundledInstallerComponent>
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
</ItemGroup>
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Include DesktopUI shared framework and toolset in redist layout
2018-10-24 23:05:02 +00:00
<PropertyGroup>
Don't include WindowsDesktop in ARM builds
2018-11-23 17:56:43 +00:00
<IncludeWpfAndWinForms Condition=" '$(IncludeWpfAndWinForms)' == '' AND '$(Architecture)' == 'arm'">false</IncludeWpfAndWinForms>
Include DesktopUI shared framework and toolset in redist layout
2018-10-24 23:05:02 +00:00
<IncludeWpfAndWinForms Condition=" '$(IncludeWpfAndWinForms)' == '' AND '$(OS)' == 'Windows_NT' ">true</IncludeWpfAndWinForms>
<IncludeWpfAndWinForms Condition=" '$(IncludeWpfAndWinForms)' == '' ">false</IncludeWpfAndWinForms>
</PropertyGroup>
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Include DesktopUI shared framework and toolset in redist layout
2018-10-24 23:05:02 +00:00
<ItemGroup Condition=" '$(IncludeWpfAndWinForms)' != 'false' ">
Don't include WindowsDesktop targeting pack in x-plat tarball (#3403)
2019-07-24 18:02:42 +00:00
<BundledLayoutPackage Include="MicrosoftWindowsDesktopAppTargetingPackNupkg">
<PackageName>Microsoft.WindowsDesktop.App.Ref</PackageName>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<PackageVersion>$(MicrosoftWindowsDesktopAppRefPackageVersion)</PackageVersion>
Don't include WindowsDesktop targeting pack in x-plat tarball (#3403)
2019-07-24 18:02:42 +00:00
<TargetFramework>$(TargetFramework)</TargetFramework>
<RelativeLayoutPath>packs/%(PackageName)/%(PackageVersion)</RelativeLayoutPath>
</BundledLayoutPackage>
Include DesktopUI shared framework and toolset in redist layout
2018-10-24 23:05:02 +00:00
<BundledLayoutComponent Include="WinFormsAndWpfSharedFxArchiveFile">
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<BaseUrl>$(WinFormsAndWpfSharedFxRootUrl)$(CoreSetupBlobVersion)</BaseUrl>
Include DesktopUI shared framework and toolset in redist layout
2018-10-24 23:05:02 +00:00
<DownloadFileName>$(WinFormsAndWpfSharedFxArchiveFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
</BundledLayoutComponent>
<BundledInstallerComponent Include="DownloadedWinFormsAndWpfSharedFrameworkInstallerFile"
Include the targeting pack MSI in the SDK bundle installation (#588) * Include the targeting pack MSI in the SDK bundle installation.
2019-02-21 00:36:11 +00:00
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' != '' And !$(Architecture.StartsWith('arm'))">
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<BaseUrl>$(WinFormsAndWpfSharedFxRootUrl)$(CoreSetupBlobVersion)</BaseUrl>
Include DesktopUI shared framework and toolset in redist layout
2018-10-24 23:05:02 +00:00
<DownloadFileName>$(DownloadedWinFormsAndWpfSharedFrameworkInstallerFileName)</DownloadFileName>
<AccessToken>$(CoreSetupBlobAccessTokenParam)</AccessToken>
</BundledInstallerComponent>
</ItemGroup>
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
</Target>
Include DesktopUI shared framework and toolset in redist layout
2018-10-24 23:05:02 +00:00
<Target Name="DownloadBundledComponents" DependsOnTargets="SetupBundledComponents">
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
<ItemGroup>
<BundledLayoutComponent>
Produce deb packages
2018-11-02 06:15:59 +00:00
<DownloadDestination>$(DownloadsFolder)%(DownloadFileName)</DownloadDestination>
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
</BundledLayoutComponent>
Add more components to download / layout
2018-10-24 07:08:51 +00:00
<BundledInstallerComponent>
Produce deb packages
2018-11-02 06:15:59 +00:00
<DownloadDestination>$(DownloadsFolder)%(DownloadFileName)</DownloadDestination>
Add more components to download / layout
2018-10-24 07:08:51 +00:00
</BundledInstallerComponent>
<ComponentToDownload Include="@(BundledLayoutComponent);@(BundledInstallerComponent)">
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
<ShouldDownload Condition="!Exists('%(DownloadDestination)')">true</ShouldDownload>
Add more components to download / layout
2018-10-24 07:08:51 +00:00
</ComponentToDownload>
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
</ItemGroup>
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Add more components to download / layout
2018-10-24 07:08:51 +00:00
<DownloadFile Condition=" '@(ComponentToDownload)' != '' And '%(ComponentToDownload.ShouldDownload)' == 'true'"
Download blobs from MSRC storage & Add CredProvider to Dockerfiles (#4753) * 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
2019-10-01 20:22:33 +00:00
Uri="%(ComponentToDownload.BaseUrl)/%(ComponentToDownload.DownloadFileName)%(ComponentToDownload.AccessToken)"
Add more components to download / layout
2018-10-24 07:08:51 +00:00
DestinationPath="%(ComponentToDownload.DownloadDestination)" />
Use .Ref targeting packs and include in layout under packs folder
2019-02-20 15:30:40 +00:00
<ItemGroup>
<BundledLayoutPackageDownloadProject Include="$(MSBuildThisFileDirectory)DownloadPackage.csproj">
<Properties>
PackageToRestore=%(BundledLayoutPackage.PackageName);
PackageVersionToRestore=%(BundledLayoutPackage.PackageVersion);
adding .Net standard 2.1 Targeting Packs (#1309) * adding .Net standard 2.1 Targeting Packs
2019-04-10 15:55:46 +00:00
TargetFramework=%(BundledLayoutPackage.TargetFramework);
Use .Ref targeting packs and include in layout under packs folder
2019-02-20 15:30:40 +00:00
LayoutPackageDescription=%(BundledLayoutPackage.Identity)
</Properties>
</BundledLayoutPackageDownloadProject>
</ItemGroup>
<MSBuild
BuildInParallel="False"
Projects="@(BundledLayoutPackageDownloadProject)">
</MSBuild>
<ItemGroup>
<!-- Use lowercase package name in package path -->
<BundledLayoutPackage>
<LoweredPackageName>$([MSBuild]::ValueOrDefault('%(BundledLayoutPackage.PackageName)', '').ToLower())</LoweredPackageName>
</BundledLayoutPackage>
<BundledLayoutPackageDownloadFiles Include="$(NuGetPackageRoot)\%(BundledLayoutPackage.LoweredPackageName)\%(BundledLayoutPackage.PackageVersion)\**\*.*">
<RelativeLayoutPath>%(BundledLayoutPackage.RelativeLayoutPath)</RelativeLayoutPath>
<LayoutPackageDescription>%(BundledLayoutPackage.Identity)</LayoutPackageDescription>
</BundledLayoutPackageDownloadFiles>
<!-- Remove files from the root of the package, as these are either files NuGet writes, or not necessary -->
<BundledLayoutPackageDownloadFiles Remove="$(NuGetPackageRoot)\%(BundledLayoutPackage.LoweredPackageName)\%(BundledLayoutPackage.PackageVersion)\*.*" />
<!-- Set destination path in layout -->
<BundledLayoutPackageDownloadFiles>
<DestinationPath>%(BundledLayoutPackageDownloadFiles.RecursiveDir)%(BundledLayoutPackageDownloadFiles.Filename)%(BundledLayoutPackageDownloadFiles.Extension)</DestinationPath>
</BundledLayoutPackageDownloadFiles>
<BundledLayoutPackageDownloadFiles>
<DestinationPath>$(RedistLayoutPath)/%(BundledLayoutPackageDownloadFiles.RelativeLayoutPath)/%(BundledLayoutPackageDownloadFiles.DestinationPath)</DestinationPath>
</BundledLayoutPackageDownloadFiles>
<BundledLayoutPackageDownloadFiles>
<DestinationPath>$([MSBuild]::NormalizePath(%(BundledLayoutPackageDownloadFiles.DestinationPath)))</DestinationPath>
</BundledLayoutPackageDownloadFiles>
<!-- Creating a new item here isn't strictly necessary, but makes it easier to see what's going on in the .binlog,
since the metadata updates don't show up there -->
<BundledLayoutPackageDownloadFilesWithDestination Include="@(BundledLayoutPackageDownloadFiles)"/>
</ItemGroup>
Include DesktopUI shared framework and toolset in redist layout
2018-10-24 23:05:02 +00:00
</Target>
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
Move layout folder
2018-10-29 19:26:31 +00:00
<Target Name="CleanLayoutPath">
Include DesktopUI shared framework and toolset in redist layout
2018-10-24 23:05:02 +00:00
<!-- Remove everything from the publish directory so we don't have left over items from previous builds -->
Move layout folder
2018-10-29 19:26:31 +00:00
<RemoveDir Directories="$(RedistLayoutPath)" />
<MakeDir Directories="$(RedistLayoutPath)" />
Include DesktopUI shared framework and toolset in redist layout
2018-10-24 23:05:02 +00:00
</Target>
Add more components to download / layout
2018-10-24 07:08:51 +00:00
Use .Ref targeting packs and include in layout under packs folder
2019-02-20 15:30:40 +00:00
<Target Name="LayoutBundledComponents">
Include DesktopUI shared framework and toolset in redist layout
2018-10-24 23:05:02 +00:00
<ExtractArchiveToDirectory SourceArchive="%(BundledLayoutComponent.DownloadDestination)"
Use .Ref targeting packs and include in layout under packs folder
2019-02-20 15:30:40 +00:00
DestinationDirectory="$(RedistLayoutPath)/%(BundledLayoutComponent.RelativeLayoutPath)" />
<Copy SourceFiles="@(BundledLayoutPackageDownloadFilesWithDestination)"
DestinationFiles="@(BundledLayoutPackageDownloadFilesWithDestination->'%(DestinationPath)')"
SkipUnchangedFiles="true"
/>
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Generate bundled versions
2018-11-12 19:52:19 +00:00
</Target>
<Target Name="RetargetTools">
<PropertyGroup>
<ReplacementPattern>"version": ".*"</ReplacementPattern>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<ReplacementString>"version": "$(MicrosoftNETCoreAppRuntimePackageVersion)"</ReplacementString>
Generate bundled versions
2018-11-12 19:52:19 +00:00
</PropertyGroup>
<ItemGroup>
<ToolRuntimeConfigPath Include="$(RedistLayoutPath)sdk/$(SdkVersion)/**/*.runtimeconfig.json" />
</ItemGroup>
<ReplaceFileContents
InputFiles="@(ToolRuntimeConfigPath)"
DestinationFiles="@(ToolRuntimeConfigPath)"
ReplacementPatterns="$(ReplacementPattern)"
ReplacementStrings="$(ReplacementString)" />
</Target>
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Generate version file
2018-11-20 18:17:29 +00:00
<Target Name="GenerateVersionFile" DependsOnTargets="SetupBundledComponents;GetCoreSdkGitCommitInfo">
<WriteLinesToFile File="$(SdkOutputDirectory).version"
Lines="$(GitCommitHash);$(SdkVersion);$(Rid)"
Overwrite="true" />
</Target>
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Include AppHostTemplate
2018-12-04 02:58:43 +00:00
<Target Name="LayoutAppHostTemplate" DependsOnTargets="RunResolvePackageDependencies">
<PropertyGroup>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
<NETCoreAppHostPackageName>Microsoft.NETCore.App.Host.$(SharedFrameworkRid)</NETCoreAppHostPackageName>
Include AppHostTemplate
2018-12-04 02:58:43 +00:00
<AppHostRestorePath>$(IntermediateOutputPath)AppHostRestore\</AppHostRestorePath>
<AppHostTemplatePath>$(SdkOutputDirectory)AppHostTemplate</AppHostTemplatePath>
</PropertyGroup>
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Include AppHostTemplate
2018-12-04 02:58:43 +00:00
<RemoveDir Directories="$(AppHostRestorePath)" />
<MakeDir Directories="$(AppHostRestorePath)" />
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Include AppHostTemplate
2018-12-04 02:58:43 +00:00
<ItemGroup>
<AppHostTemplateDownloadPackageProject Include="$(MSBuildThisFileDirectory)DownloadPackage.csproj">
<Properties>
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
PackageToRestore=$(NETCoreAppHostPackageName);
PackageVersionToRestore=$(MicrosoftNETCoreAppHostPackageVersion);
Include AppHostTemplate
2018-12-04 02:58:43 +00:00
TargetFramework=$(TargetFramework);
RestorePackagesPath=$(AppHostRestorePath);
RuntimeIdentifier=$(Rid)
</Properties>
</AppHostTemplateDownloadPackageProject>
</ItemGroup>
<MSBuild
BuildInParallel="False"
Projects="@(AppHostTemplateDownloadPackageProject)">
</MSBuild>
<PropertyGroup>
<AppHostExecutableName>AppHost$(ExeExtension)</AppHostExecutableName>
</PropertyGroup>
<ItemGroup>
<AllFileOfRestoredAppHostPackage Include="$(AppHostRestorePath)\**\*.*" />
<NativeRestoredAppHostNETCore
Include="@(AllFileOfRestoredAppHostPackage)"
Condition="'%(FileName)%(Extension)' == '$(AppHostExecutableName)'"/>
</ItemGroup>
<Error Condition="@(NativeRestoredAppHostNETCore->Distinct()->Count()) != 1"
Prepare for 3.0.1xx servicing 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.
2019-10-03 17:33:20 +00:00
Text="Failed to determine the $(NETCoreAppHostPackageName) executable in @(AllFileOfRestoredAppHostPackage)" />
Include AppHostTemplate
2018-12-04 02:58:43 +00:00
<Copy
SourceFiles="@(NativeRestoredAppHostNETCore)"
DestinationFolder="$(AppHostTemplatePath)" />
<Message Text="Copy from @(NativeRestoredAppHostNETCore) to $(AppHostTemplatePath)."
Importance="High" />
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Include AppHostTemplate
2018-12-04 02:58:43 +00:00
</Target>
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Generate bundled versions
2018-11-12 19:52:19 +00:00
<Target Name="GenerateLayout"
DependsOnTargets="DownloadBundledComponents;
CleanLayoutPath;
Use .Ref targeting packs and include in layout under packs folder
2019-02-20 15:30:40 +00:00
LayoutBundledComponents;
Generate version file
2018-11-20 18:17:29 +00:00
GenerateVersionFile;
Generate bundled versions
2018-11-12 19:52:19 +00:00
GenerateBundledVersions;
Bundle runtime graph file in SDK
2019-01-03 22:58:20 +00:00
LayoutRuntimeGraph;
Include templates in layout
2018-11-12 23:23:44 +00:00
LayoutTemplates;
Include bundled tools in layout
2018-11-13 23:04:44 +00:00
LayoutBundledTools;
Crossgen layout
2018-12-04 02:15:31 +00:00
RetargetTools;
Sign layout
2018-12-04 21:20:28 +00:00
CrossgenLayout;
Fixing debs generation. The issue was that we were losing the exec permission on the apphost in the sdk folder. This caused it to not be picked up by dh_shlibsdeps. This happened because the order of the apphost acquisition was changed to be after crossgen, where we change permissions of all files under the SDK folder to 644. The fix here was to make the apphost acquisition to happen after crossgen.
2018-12-24 18:12:23 +00:00
LayoutAppHostTemplate;
Sign layout
2018-12-04 21:20:28 +00:00
SignLayout"
Add package with MSBuild SDK resolver for internal build consumption (#478) * Add package with MSBuild SDK resolver for internal build consumption * Fix `dotnet pack` of redist.csproj without having built everything first
2019-02-15 02:21:23 +00:00
BeforeTargets="AfterBuild">
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Generate bundled versions
2018-11-12 19:52:19 +00:00
</Target>
Do not download for 'arm*'
2019-09-09 19:51:24 +00:00
Generate bundled versions
2018-11-12 19:52:19 +00:00
<Target Name="GenerateInternalLayout"
DependsOnTargets="GenerateLayout"
Add package with MSBuild SDK resolver for internal build consumption (#478) * Add package with MSBuild SDK resolver for internal build consumption * Fix `dotnet pack` of redist.csproj without having built everything first
2019-02-15 02:21:23 +00:00
BeforeTargets="AfterBuild">
Generate Windows installers
2018-10-31 20:56:32 +00:00
Generate bundled versions
2018-11-12 19:52:19 +00:00
<RemoveDir Directories="$(SdkInternalLayoutPath)" />
<MakeDir Directories="$(SdkInternalLayoutPath)" />
Generate Windows installers
2018-10-31 20:56:32 +00:00
<!-- Create "SDK Internal" layout to create the MSI to bundle -->
Generate bundled versions
2018-11-12 19:52:19 +00:00
<ItemGroup>
<SdkInternalFiles Include="$(RedistLayoutPath)sdk/$(SdkVersion)/**/*.*"/>
</ItemGroup>
<Copy SourceFiles="@(SdkInternalFiles)"
Fixes the layout of the dotnet-internal artifacts, which are used by the chained pkg, msi and -internal.zips/tarballs. We were flattenning all files in the folder.
2018-12-27 23:33:02 +00:00
DestinationFiles="@(SdkInternalFiles -> '$(SdkInternalLayoutPath)sdk\$(SdkVersion)\%(RecursiveDir)%(Filename)%(Extension)')"/>
Generate bundled versions
2018-11-12 19:52:19 +00:00
Set up infrastructure to download bundled components for layout
2018-10-24 01:16:45 +00:00
</Target>
</Project>
Reference in a new issue Copy permalink