2018-10-24 01:16:45 +00:00
<Project>
2018-10-29 19:26:31 +00:00
<PropertyGroup>
<RedistLayoutPath>$(BaseOutputPath)$(Configuration)\dotnet\</RedistLayoutPath>
2018-10-31 20:56:32 +00:00
<SdkInternalLayoutPath>$(BaseOutputPath)$(Configuration)\dotnet-internal\</SdkInternalLayoutPath>
2020-03-02 21:23:21 +00:00
<Templates50LayoutPath>$(BaseOutputPath)$(Configuration)\templates-5.0\</Templates50LayoutPath>
2019-09-20 22:20:01 +00:00
<Templates31LayoutPath>$(BaseOutputPath)$(Configuration)\templates-3.1\</Templates31LayoutPath>
2019-07-17 23:18:41 +00:00
<Templates30LayoutPath>$(BaseOutputPath)$(Configuration)\templates-3.0\</Templates30LayoutPath>
<Templates21LayoutPath>$(BaseOutputPath)$(Configuration)\templates-2.1\</Templates21LayoutPath>
2018-11-02 06:15:59 +00:00
<DownloadsFolder>$(IntermediateOutputPath)downloads\</DownloadsFolder>
2018-10-29 19:26:31 +00:00
</PropertyGroup>
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 -->
2019-12-05 23:41:25 +00:00
<AspNetCoreBlobVersion>$(VSRedistCommonAspNetCoreTargetingPackx6450PackageVersion)</AspNetCoreBlobVersion>
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
<CoreSetupBlobVersion>$(MicrosoftNETCoreAppInternalPackageVersion)</CoreSetupBlobVersion>
2019-10-23 15:26:09 +00:00
<WindowsDesktopBlobVersion>$(MicrosoftWindowsDesktopAppPackageVersion)</WindowsDesktopBlobVersion>
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
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>
2019-10-19 01:11:18 +00:00
<AspNetCoreTargetingPackBlobVersion>$(AspNetCoreBlobVersion)</AspNetCoreTargetingPackBlobVersion>
2019-10-23 15:26:09 +00:00
<WindowsDesktopTargetingPackBlobVersion>$(WindowsDesktopBlobVersion)</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>
2019-09-16 00:27:29 +00:00
</PropertyGroup>
2019-12-07 23:05:24 +00:00
2019-12-20 21:13:26 +00:00
<Target Name="SetupBundledComponents" DependsOnTargets="GetCurrentRuntimeInformation;SetupFileExtensions;SetBuildDefaults">
2018-10-24 01:16:45 +00:00
<PropertyGroup>
2019-12-20 21:13:26 +00:00
<SdkOutputDirectory>$(RedistLayoutPath)sdk\$(Version)\</SdkOutputDirectory>
2019-10-01 20:22:33 +00:00
2019-12-07 23:05:24 +00:00
<InternalBuild Condition="$(SYSTEM_TEAMPROJECT) == 'internal'">true</InternalBuild>
<InternalBaseURL Condition="$(SYSTEM_TEAMPROJECT) == 'internal'">https://dotnetclimsrc.blob.core.windows.net/dotnet/</InternalBaseURL>
2019-10-01 20:22:33 +00:00
2019-12-07 23:05:24 +00:00
<CoreSetupBlobRootUrl Condition="'$(CoreSetupBlobRootUrl)' == ''">https://dotnetcli.blob.core.windows.net/dotnet/</CoreSetupBlobRootUrl>
2019-02-02 22:34:04 +00:00
<DotnetExtensionsBlobRootUrl Condition="'$(DotnetExtensionsBlobRootUrl)' == ''">https://dotnetcli.blob.core.windows.net/dotnet/</DotnetExtensionsBlobRootUrl>
2020-03-04 16:51:08 +00:00
<DotnetToolsetBlobRootUrl Condition="'$(DotnetToolsetBlobRootUrl)' == ''">https://dotnetfeed.blob.core.windows.net/dotnet-core/</DotnetToolsetBlobRootUrl>
2019-09-09 19:51:24 +00:00
2019-03-10 05:21:04 +00:00
<CoreSetupRid Condition="'$(CoreSetupRid)' == ''">$(HostRid)</CoreSetupRid>
2020-05-06 14:59:23 +00:00
<CoreSetupRid Condition=" ('$(OSName)' == 'win' or '$(OSName)' == 'osx' or '$(OSName)' == 'freebsd') and '$(DotNetBuildFromSource)' != 'true' ">$(OSName)-$(Architecture)</CoreSetupRid>
2018-10-24 01:16:45 +00:00
<!-- only the runtime OSX .pkgs have a `-internal` suffix -->
2020-05-06 14:59:23 +00:00
<InstallerStartSuffix Condition="$([MSBuild]::IsOSPlatform('OSX'))">-internal</InstallerStartSuffix>
2018-10-24 01:16:45 +00:00
<!-- Downloaded Installers + Archives -->
<!-- Use the "x64" Rid when downloading Linux shared framework 'DEB' installer files. -->
<SharedFrameworkInstallerFileRid>$(CoreSetupRid)</SharedFrameworkInstallerFileRid>
2019-11-07 16:33:59 +00:00
<SharedFrameworkInstallerFileRid Condition=" '$(IsDebianBaseDistro)' == 'true' OR '$(IsRPMBasedDistro)' == 'true' ">$(Architecture)</SharedFrameworkInstallerFileRid>
2018-10-24 01:16:45 +00:00
2019-05-03 22:18:14 +00:00
<!-- Use the "x64" Rid when downloading Linux runtime dependencies Debian package. -->
<RuntimeDepsInstallerFileRid>$(CoreSetupRid)</RuntimeDepsInstallerFileRid>
2019-11-07 16:33:59 +00:00
<RuntimeDepsInstallerFileRid Condition=" '$(IsDebianBaseDistro)' == 'true' ">$(Architecture)</RuntimeDepsInstallerFileRid>
2019-05-03 22:18:14 +00:00
2019-09-24 17:36:04 +00:00
<AlternateArchitecture Condition="'$(Architecture)' == 'x86'">x64</AlternateArchitecture>
<AlternateArchitecture Condition="'$(Architecture)' == 'x64'">x86</AlternateArchitecture>
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>
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>
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>
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>
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>
2019-10-18 23:19:05 +00:00
<CombinedFrameworkHostArchiveFileName>dotnet-runtime-$(MicrosoftNETCoreAppRuntimePackageVersion)-$(SharedFrameworkRid)$(ArchiveExtension)</CombinedFrameworkHostArchiveFileName>
2019-10-19 00:12:15 +00:00
<WinFormsAndWpfSharedFxArchiveFileName>windowsdesktop-runtime-$(MicrosoftWindowsDesktopAppRuntimePackageVersion)-$(SharedFrameworkRid)$(ArchiveExtension)</WinFormsAndWpfSharedFxArchiveFileName>
2018-10-24 01:16:45 +00:00
2019-09-11 22:45:08 +00:00
<AspNetCoreSharedFxInstallerRid Condition="'$(AspNetCoreSharedFxInstallerRid)' == ''">$(SharedFrameworkRid)</AspNetCoreSharedFxInstallerRid>
2019-11-11 18:53:58 +00:00
<AspNetCoreSharedFxInstallerRid Condition="'$(SharedFrameworkRid)' == 'rhel.6-x64'">linux-x64</AspNetCoreSharedFxInstallerRid>
2018-10-24 01:16:45 +00:00
<AspNetCoreSharedFxArchiveRid>$(AspNetCoreSharedFxInstallerRid)</AspNetCoreSharedFxArchiveRid>
<AspNetCoreSharedFxInstallerRid Condition="'$(InstallerExtension)' == '.deb' OR '$(InstallerExtension)' == '.rpm'">x64</AspNetCoreSharedFxInstallerRid>
2020-05-06 14:59:23 +00:00
<DownloadedAspNetCoreSharedFxInstallerFileName Condition=" '$(InstallerExtension)' != '' AND !$([MSBuild]::IsOSPlatform('OSX')) ">aspnetcore-runtime-$(MicrosoftAspNetCoreAppRuntimePackageVersion)-$(AspNetCoreSharedFxInstallerRid)$(InstallerExtension)</DownloadedAspNetCoreSharedFxInstallerFileName>
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. -->
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>
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>
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>
2019-10-08 17:50:59 +00:00
<WinFormsAndWpfSharedFxRootUrl>$(CoreSetupBlobRootUrl)WindowsDesktop/</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>
2018-10-24 01:16:45 +00:00
<CombinedSharedHostAndFrameworkArchive>$(CoreSetupDownloadDirectory)/combinedSharedHostAndFrameworkArchive$(ArchiveExtension)</CombinedSharedHostAndFrameworkArchive>
</PropertyGroup>
2019-02-26 19:09:56 +00:00
2020-05-06 14:59:23 +00:00
<PropertyGroup Condition="$([MSBuild]::IsOSPlatform('WINDOWS')) And !$(Architecture.StartsWith('arm'))">
2019-09-24 17:36:04 +00:00
<AlternateAppHostRid>win-$(AlternateArchitecture)</AlternateAppHostRid>
<ArmAppHostRid>win-arm</ArmAppHostRid>
<Arm64AppHostRid>win-arm64</Arm64AppHostRid>
2018-10-24 01:16:45 +00:00
</PropertyGroup>
2019-04-17 19:53:05 +00:00
2018-10-24 01:16:45 +00:00
<ItemGroup>
<BundledLayoutComponent Include="CombinedSharedHostAndFrameworkArchive">
2019-10-25 20:54:21 +00:00
<BaseUrl>$(CoreSetupRootUrl)$(CoreSetupBlobVersion)</BaseUrl>
2019-09-09 19:38:32 +00:00
<DownloadFileName>$(CombinedFrameworkHostArchiveFileName)</DownloadFileName>
2018-10-24 01:16:45 +00:00
<RelativeLayoutPath></RelativeLayoutPath>
</BundledLayoutComponent>
2018-10-24 07:08:51 +00:00
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>
2019-04-10 15:55:46 +00:00
<TargetFramework>$(TargetFramework)</TargetFramework>
2019-02-20 15:30:40 +00:00
<RelativeLayoutPath>packs/%(PackageName)/%(PackageVersion)</RelativeLayoutPath>
</BundledLayoutPackage>
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>
2019-09-09 19:51:24 +00:00
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>
2019-04-10 15:55:46 +00:00
<TargetFramework>$(TargetFramework)</TargetFramework>
2019-02-20 15:30:40 +00:00
<RelativeLayoutPath>packs/%(PackageName)/%(PackageVersion)</RelativeLayoutPath>
</BundledLayoutPackage>
2019-02-26 19:09:56 +00:00
<BundledLayoutPackage Include="MicrosoftNetCoreAppHostPackNupkg">
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>
2019-04-10 15:55:46 +00:00
<TargetFramework>$(TargetFramework)</TargetFramework>
2019-02-26 19:09:56 +00:00
<RelativeLayoutPath>packs/%(PackageName)/%(PackageVersion)</RelativeLayoutPath>
</BundledLayoutPackage>
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>
2019-04-10 15:55:46 +00:00
<TargetFramework>$(TargetFramework)</TargetFramework>
2019-02-26 19:09:56 +00:00
<RelativeLayoutPath>packs/%(PackageName)/%(PackageVersion)</RelativeLayoutPath>
</BundledLayoutPackage>
2019-09-24 17:36:04 +00:00
<BundledLayoutPackage Include="MicrosoftNetCoreAppHostPackNupkg_Arm" Condition="'$(ArmAppHostRid)' != ''">
<PackageName>Microsoft.NETCore.App.Host.$(ArmAppHostRid)</PackageName>
2019-10-19 00:12:15 +00:00
<PackageVersion>$(MicrosoftNETCoreAppHostPackageVersion)</PackageVersion>
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>
2019-10-19 00:12:15 +00:00
<PackageVersion>$(MicrosoftNETCoreAppHostPackageVersion)</PackageVersion>
2019-09-24 17:36:04 +00:00
<TargetFramework>$(TargetFramework)</TargetFramework>
<RelativeLayoutPath>packs/%(PackageName)/%(PackageVersion)</RelativeLayoutPath>
</BundledLayoutPackage>
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>
2018-10-24 07:08:51 +00:00
<DownloadFileName>$(DownloadedRuntimeDepsInstallerFileName)</DownloadFileName>
</BundledInstallerComponent>
2019-09-09 19:51:24 +00:00
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>
2018-10-24 07:08:51 +00:00
<DownloadFileName>$(DownloadedSharedFrameworkInstallerFileName)</DownloadFileName>
</BundledInstallerComponent>
2019-09-09 19:51:24 +00:00
2018-10-24 07:08:51 +00:00
<BundledInstallerComponent Include="DownloadedSharedHostInstallerFile"
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>
2018-10-24 07:08:51 +00:00
<DownloadFileName>$(DownloadedSharedHostInstallerFileName)</DownloadFileName>
</BundledInstallerComponent>
2019-09-09 19:51:24 +00:00
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>
2018-10-24 07:08:51 +00:00
<DownloadFileName>$(DownloadedHostFxrInstallerFileName)</DownloadFileName>
</BundledInstallerComponent>
2019-09-09 19:51:24 +00:00
2019-02-21 00:36:11 +00:00
<BundledInstallerComponent Include="DownloadedNetCoreAppTargetingPackInstallerFile"
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>
2019-02-21 00:36:11 +00:00
<DownloadFileName>$(DownloadedNetCoreAppTargetingPackInstallerFileName)</DownloadFileName>
</BundledInstallerComponent>
2019-03-19 21:15:32 +00:00
2019-04-10 15:55:46 +00:00
<BundledInstallerComponent Include="DownloadedNetStandardTargetingPackInstallerFile"
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' != '' And !$(Architecture.StartsWith('arm'))">
2019-10-23 15:26:09 +00:00
<BaseUrl>$(CoreSetupRootUrl)$(NETCoreAppTargetingPackBlobVersion)</BaseUrl>
2019-09-24 19:48:28 +00:00
<BaseUrl>$(CoreSetupRootUrl)3.0.0</BaseUrl>
2019-04-10 15:55:46 +00:00
<DownloadFileName>$(DownloadedNetStandardTargetingPackInstallerFileName)</DownloadFileName>
</BundledInstallerComponent>
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>
2019-04-17 19:53:05 +00:00
<DownloadFileName>$(DownloadedNetCoreAppHostPackInstallerFileName)</DownloadFileName>
</BundledInstallerComponent>
2019-09-24 17:36:04 +00:00
<BundledInstallerComponent Include="DownloadedAlternateNetCoreAppHostPackInstallerFile"
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' == '.msi' And !$(Architecture.StartsWith('arm'))">
2019-10-19 00:12:15 +00:00
<BaseUrl>$(CoreSetupRootUrl)$(CoreSetupBlobVersion)</BaseUrl>
2019-09-24 17:36:04 +00:00
<DownloadFileName>$(DownloadedAlternateNetCoreAppHostPackInstallerFileName)</DownloadFileName>
</BundledInstallerComponent>
<BundledInstallerComponent Include="DownloadedArmNetCoreAppHostPackInstallerFile"
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' == '.msi' And !$(Architecture.StartsWith('arm'))">
2019-10-19 00:12:15 +00:00
<BaseUrl>$(CoreSetupRootUrl)$(CoreSetupBlobVersion)</BaseUrl>
2019-09-24 17:36:04 +00:00
<DownloadFileName>$(DownloadedArmNetCoreAppHostPackInstallerFileName)</DownloadFileName>
</BundledInstallerComponent>
<BundledInstallerComponent Include="DownloadedArm64NetCoreAppHostPackInstallerFile"
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' == '.msi' And !$(Architecture.StartsWith('arm'))">
2019-10-19 00:12:15 +00:00
<BaseUrl>$(CoreSetupRootUrl)$(CoreSetupBlobVersion)</BaseUrl>
2019-09-24 17:36:04 +00:00
<DownloadFileName>$(DownloadedArm64NetCoreAppHostPackInstallerFileName)</DownloadFileName>
2019-04-17 19:53:05 +00:00
</BundledInstallerComponent>
2019-09-09 19:51:24 +00:00
2019-04-01 21:24:56 +00:00
<BundledInstallerComponent Include="DownloadedWindowsDesktopTargetingPackInstallerFile"
2019-03-19 21:15:32 +00:00
Condition="'$(InstallerExtension)' == '.msi' And '$(SkipBuildingInstallers)' != 'true' And !$(Architecture.StartsWith('arm'))">
2019-10-23 15:26:09 +00:00
<BaseUrl>$(WinFormsAndWpfSharedFxRootUrl)$(WindowsDesktopTargetingPackBlobVersion)</BaseUrl>
2019-03-19 21:15:32 +00:00
<DownloadFileName>$(DownloadedWindowsDesktopTargetingPackInstallerFileName)</DownloadFileName>
</BundledInstallerComponent>
2018-10-24 23:05:02 +00:00
<BundledLayoutComponent Include="ToolsetArchive">
2020-03-04 16:51:08 +00:00
<BaseUrl>$(DotnetToolsetBlobRootUrl)Sdk/$(MicrosoftDotnetToolsetInternalPackageVersion)</BaseUrl>
2019-01-15 23:37:37 +00:00
<DownloadFileName>dotnet-toolset-internal-$(MicrosoftDotnetToolsetInternalPackageVersion).zip</DownloadFileName>
2019-12-20 21:13:26 +00:00
<RelativeLayoutPath>sdk/$(Version)</RelativeLayoutPath>
2018-10-24 23:05:02 +00:00
</BundledLayoutComponent>
2018-10-24 07:08:51 +00:00
</ItemGroup>
2019-03-19 21:15:32 +00:00
2018-10-24 07:08:51 +00:00
<ItemGroup Condition=" '$(IncludeAspNetCoreRuntime)' != 'false' ">
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>
2018-10-24 07:08:51 +00:00
<DownloadFileName>$(AspNetCoreSharedFxArchiveFileName)</DownloadFileName>
<RelativeLayoutPath></RelativeLayoutPath>
</BundledLayoutComponent>
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>
2019-04-02 22:51:47 +00:00
<DownloadFileName>$(AspNetTargetingPackArchiveFileName)</DownloadFileName>
<RelativeLayoutPath></RelativeLayoutPath>
</BundledLayoutComponent>
2019-09-09 19:51:24 +00:00
2019-02-21 00:36:11 +00:00
<BundledInstallerComponent Include="DownloadedAspNetTargetingPackInstallerFile"
2019-04-01 21:24:56 +00:00
Condition="'$(InstallerExtension)' != '.pkg' And '$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' != '' And !$(Architecture.StartsWith('arm'))">
2019-11-05 05:42:29 +00:00
<BaseUrl>$(AspNetCoreSharedFxRootUrl)$(AspNetCoreTargetingPackBlobVersion)</BaseUrl>
2019-02-21 00:36:11 +00:00
<DownloadFileName>$(DownloadedAspNetTargetingPackInstallerFileName)</DownloadFileName>
</BundledInstallerComponent>
2019-03-19 21:15:32 +00:00
2018-10-24 07:08:51 +00:00
<BundledInstallerComponent Include="DownloadedAspNetCoreSharedFxInstallerFile"
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>
2018-10-24 07:08:51 +00:00
<DownloadFileName>$(DownloadedAspNetCoreSharedFxInstallerFileName)</DownloadFileName>
</BundledInstallerComponent>
2019-09-09 19:38:32 +00:00
<BundledInstallerComponent Include="DownloadedAspNetCoreSharedFxWixLibFile"
2019-09-09 19:51:24 +00:00
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' == '.msi' And !$(Architecture.StartsWith('arm'))">
2019-10-18 23:19:05 +00:00
<BaseUrl>$(AspNetCoreSharedFxRootUrl)$(AspNetCoreBlobVersion)</BaseUrl>
2019-09-09 19:38:32 +00:00
<DownloadFileName>$(DownloadedAspNetCoreSharedFxWixLibFileName)</DownloadFileName>
</BundledInstallerComponent>
<BundledInstallerComponent Include="DownloadedAspNetCoreV2ModuleInstallerFile"
2019-09-09 19:51:24 +00:00
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' == '.msi' And !$(Architecture.StartsWith('arm'))">
2019-10-18 23:19:05 +00:00
<BaseUrl>$(AspNetCoreSharedFxRootUrl)$(AspNetCoreBlobVersion)</BaseUrl>
2019-09-09 19:38:32 +00:00
<DownloadFileName>$(DownloadedAspNetCoreV2ModuleInstallerFileName)</DownloadFileName>
</BundledInstallerComponent>
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>
2018-10-24 07:08:51 +00:00
<DownloadFileName>$(AspNetCoreSharedFxBaseRuntimeVersionFileName)</DownloadFileName>
</BundledInstallerComponent>
2018-10-24 01:16:45 +00:00
</ItemGroup>
2019-09-09 19:51:24 +00:00
2018-10-24 23:05:02 +00:00
<PropertyGroup>
2018-11-23 17:56:43 +00:00
<IncludeWpfAndWinForms Condition=" '$(IncludeWpfAndWinForms)' == '' AND '$(Architecture)' == 'arm'">false</IncludeWpfAndWinForms>
2020-03-06 23:51:55 +00:00
<IncludeWpfAndWinForms Condition=" '$(IncludeWpfAndWinForms)' == '' AND '$(OS)' == 'Windows_NT' AND '$(Architecture)' != 'arm64' ">true</IncludeWpfAndWinForms>
2018-10-24 23:05:02 +00:00
<IncludeWpfAndWinForms Condition=" '$(IncludeWpfAndWinForms)' == '' ">false</IncludeWpfAndWinForms>
</PropertyGroup>
2019-09-09 19:51:24 +00:00
2018-10-24 23:05:02 +00:00
<ItemGroup Condition=" '$(IncludeWpfAndWinForms)' != 'false' ">
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>
2019-07-24 18:02:42 +00:00
<TargetFramework>$(TargetFramework)</TargetFramework>
<RelativeLayoutPath>packs/%(PackageName)/%(PackageVersion)</RelativeLayoutPath>
</BundledLayoutPackage>
2018-10-24 23:05:02 +00:00
<BundledLayoutComponent Include="WinFormsAndWpfSharedFxArchiveFile">
2019-10-23 15:26:09 +00:00
<BaseUrl>$(WinFormsAndWpfSharedFxRootUrl)$(WindowsDesktopTargetingPackBlobVersion)</BaseUrl>
2018-10-24 23:05:02 +00:00
<DownloadFileName>$(WinFormsAndWpfSharedFxArchiveFileName)</DownloadFileName>
</BundledLayoutComponent>
<BundledInstallerComponent Include="DownloadedWinFormsAndWpfSharedFrameworkInstallerFile"
2019-02-21 00:36:11 +00:00
Condition="'$(SkipBuildingInstallers)' != 'true' And '$(InstallerExtension)' != '' And !$(Architecture.StartsWith('arm'))">
2019-10-23 15:26:09 +00:00
<BaseUrl>$(WinFormsAndWpfSharedFxRootUrl)$(WindowsDesktopBlobVersion)</BaseUrl>
2018-10-24 23:05:02 +00:00
<DownloadFileName>$(DownloadedWinFormsAndWpfSharedFrameworkInstallerFileName)</DownloadFileName>
</BundledInstallerComponent>
</ItemGroup>
2018-10-24 01:16:45 +00:00
</Target>
2018-10-24 23:05:02 +00:00
<Target Name="DownloadBundledComponents" DependsOnTargets="SetupBundledComponents">
2018-10-24 01:16:45 +00:00
<ItemGroup>
<BundledLayoutComponent>
2018-11-02 06:15:59 +00:00
<DownloadDestination>$(DownloadsFolder)%(DownloadFileName)</DownloadDestination>
2018-10-24 01:16:45 +00:00
</BundledLayoutComponent>
2018-10-24 07:08:51 +00:00
<BundledInstallerComponent>
2018-11-02 06:15:59 +00:00
<DownloadDestination>$(DownloadsFolder)%(DownloadFileName)</DownloadDestination>
2018-10-24 07:08:51 +00:00
</BundledInstallerComponent>
<ComponentToDownload Include="@(BundledLayoutComponent);@(BundledInstallerComponent)">
2018-10-24 01:16:45 +00:00
<ShouldDownload Condition="!Exists('%(DownloadDestination)')">true</ShouldDownload>
2019-12-07 23:05:24 +00:00
<!--
Replaces the public base url with the private one.
-->
<PrivateBaseUrl>%(BaseUrl)</PrivateBaseUrl>
<PrivateBaseUrl Condition="'$(InternalBuild)' == 'true'">$([System.String]::new('%(ComponentToDownload.PrivateBaseUrl)').Replace('$(CoreSetupBlobRootUrl)', '$(InternalBaseURL)'))</PrivateBaseUrl>
<PrivateBaseUrl Condition="'$(InternalBuild)' == 'true'">$([System.String]::new('%(ComponentToDownload.PrivateBaseUrl)').Replace('$(DotnetExtensionsBlobRootUrl)', '$(InternalBaseURL)'))</PrivateBaseUrl>
<PrivateBaseUrl Condition="'$(InternalBuild)' == 'true'">$([System.String]::new('%(ComponentToDownload.PrivateBaseUrl)').Replace('$(DotnetToolsetBlobRootUrl)', '$(InternalBaseURL)'))</PrivateBaseUrl>
2018-10-24 07:08:51 +00:00
</ComponentToDownload>
2018-10-24 01:16:45 +00:00
</ItemGroup>
2019-09-09 19:51:24 +00:00
2018-10-24 07:08:51 +00:00
<DownloadFile Condition=" '@(ComponentToDownload)' != '' And '%(ComponentToDownload.ShouldDownload)' == 'true'"
2019-12-07 23:05:24 +00:00
Uri="%(ComponentToDownload.BaseUrl)/%(ComponentToDownload.DownloadFileName)"
PrivateUri="%(ComponentToDownload.PrivateBaseUrl)/%(ComponentToDownload.DownloadFileName)$(DOTNETCLIMSRC_READ_SAS_TOKEN)"
2018-10-24 07:08:51 +00:00
DestinationPath="%(ComponentToDownload.DownloadDestination)" />
2019-02-20 15:30:40 +00:00
<ItemGroup>
<BundledLayoutPackageDownloadProject Include="$(MSBuildThisFileDirectory)DownloadPackage.csproj">
<Properties>
PackageToRestore=%(BundledLayoutPackage.PackageName);
PackageVersionToRestore=%(BundledLayoutPackage.PackageVersion);
2019-04-10 15:55:46 +00:00
TargetFramework=%(BundledLayoutPackage.TargetFramework);
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>
2019-12-07 23:05:24 +00:00
2019-02-20 15:30:40 +00:00
<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>
2018-10-24 23:05:02 +00:00
</Target>
2018-10-24 01:16:45 +00:00
2018-10-29 19:26:31 +00:00
<Target Name="CleanLayoutPath">
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 -->
2018-10-29 19:26:31 +00:00
<RemoveDir Directories="$(RedistLayoutPath)" />
<MakeDir Directories="$(RedistLayoutPath)" />
2018-10-24 23:05:02 +00:00
</Target>
2018-10-24 07:08:51 +00:00
2019-02-20 15:30:40 +00:00
<Target Name="LayoutBundledComponents">
2018-10-24 23:05:02 +00:00
<ExtractArchiveToDirectory SourceArchive="%(BundledLayoutComponent.DownloadDestination)"
2019-02-20 15:30:40 +00:00
DestinationDirectory="$(RedistLayoutPath)/%(BundledLayoutComponent.RelativeLayoutPath)" />
<Copy SourceFiles="@(BundledLayoutPackageDownloadFilesWithDestination)"
DestinationFiles="@(BundledLayoutPackageDownloadFilesWithDestination->'%(DestinationPath)')"
SkipUnchangedFiles="true"
/>
2019-09-09 19:51:24 +00:00
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>
2018-11-12 19:52:19 +00:00
</PropertyGroup>
<ItemGroup>
2019-12-20 21:13:26 +00:00
<ToolRuntimeConfigPath Include="$(RedistLayoutPath)sdk/$(Version)/**/*.runtimeconfig.json" />
2018-11-12 19:52:19 +00:00
</ItemGroup>
<ReplaceFileContents
InputFiles="@(ToolRuntimeConfigPath)"
DestinationFiles="@(ToolRuntimeConfigPath)"
ReplacementPatterns="$(ReplacementPattern)"
ReplacementStrings="$(ReplacementString)" />
</Target>
2019-09-09 19:51:24 +00:00
2020-01-10 05:13:46 +00:00
<Target Name="GenerateVersionFile"
DependsOnTargets="SetupBundledComponents;GetCommitHash;GenerateFullNuGetVersion">
2018-11-20 18:17:29 +00:00
<WriteLinesToFile File="$(SdkOutputDirectory).version"
2019-12-20 21:13:26 +00:00
Lines="$(GitCommitHash);$(Version);$(Rid)"
2018-11-20 18:17:29 +00:00
Overwrite="true" />
2020-01-10 05:13:46 +00:00
<!-- This is a hack to make the full nuget version available during the publishing step -->
<WriteLinesToFile File="$(ArtifactsTmpDir)FullNugetVersion.version"
Lines="$(FullNugetVersion)"
2018-11-20 18:17:29 +00:00
Overwrite="true" />
</Target>
2019-09-09 19:51:24 +00:00
2018-12-04 02:58:43 +00:00
<Target Name="LayoutAppHostTemplate" DependsOnTargets="RunResolvePackageDependencies">
2019-12-07 23:05:24 +00:00
2018-12-04 02:58:43 +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
<NETCoreAppHostPackageName>Microsoft.NETCore.App.Host.$(SharedFrameworkRid)</NETCoreAppHostPackageName>
2018-12-04 02:58:43 +00:00
<AppHostRestorePath>$(IntermediateOutputPath)AppHostRestore\</AppHostRestorePath>
<AppHostTemplatePath>$(SdkOutputDirectory)AppHostTemplate</AppHostTemplatePath>
</PropertyGroup>
2019-09-09 19:51:24 +00:00
2018-12-04 02:58:43 +00:00
<RemoveDir Directories="$(AppHostRestorePath)" />
<MakeDir Directories="$(AppHostRestorePath)" />
2019-09-09 19:51:24 +00:00
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);
2018-12-04 02:58:43 +00:00
TargetFramework=$(TargetFramework);
RestorePackagesPath=$(AppHostRestorePath);
RuntimeIdentifier=$(Rid)
</Properties>
</AppHostTemplateDownloadPackageProject>
</ItemGroup>
<MSBuild
BuildInParallel="False"
Projects="@(AppHostTemplateDownloadPackageProject)">
</MSBuild>
2019-12-07 23:05:24 +00:00
2018-12-04 02:58:43 +00:00
<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)" />
2018-12-04 02:58:43 +00:00
<Copy
SourceFiles="@(NativeRestoredAppHostNETCore)"
DestinationFolder="$(AppHostTemplatePath)" />
<Message Text="Copy from @(NativeRestoredAppHostNETCore) to $(AppHostTemplatePath)."
Importance="High" />
2019-09-09 19:51:24 +00:00
2018-12-04 02:58:43 +00:00
</Target>
2019-09-09 19:51:24 +00:00
2018-11-12 19:52:19 +00:00
<Target Name="GenerateLayout"
DependsOnTargets="DownloadBundledComponents;
CleanLayoutPath;
2019-02-20 15:30:40 +00:00
LayoutBundledComponents;
2020-01-03 21:58:21 +00:00
GenerateFullNuGetVersion;
2018-11-20 18:17:29 +00:00
GenerateVersionFile;
2018-11-12 19:52:19 +00:00
GenerateBundledVersions;
2019-01-03 22:58:20 +00:00
LayoutRuntimeGraph;
2018-11-12 23:23:44 +00:00
LayoutTemplates;
2018-11-13 23:04:44 +00:00
LayoutBundledTools;
2018-12-04 02:15:31 +00:00
RetargetTools;
2018-12-04 21:20:28 +00:00
CrossgenLayout;
2018-12-24 18:12:23 +00:00
LayoutAppHostTemplate;
2018-12-04 21:20:28 +00:00
SignLayout"
2019-02-15 02:21:23 +00:00
BeforeTargets="AfterBuild">
2019-09-09 19:51:24 +00:00
2018-11-12 19:52:19 +00:00
</Target>
2019-09-09 19:51:24 +00:00
2018-11-12 19:52:19 +00:00
<Target Name="GenerateInternalLayout"
DependsOnTargets="GenerateLayout"
2019-02-15 02:21:23 +00:00
BeforeTargets="AfterBuild">
2018-10-31 20:56:32 +00:00
2018-11-12 19:52:19 +00:00
<RemoveDir Directories="$(SdkInternalLayoutPath)" />
<MakeDir Directories="$(SdkInternalLayoutPath)" />
2019-12-07 23:05:24 +00:00
2018-10-31 20:56:32 +00:00
<!-- Create "SDK Internal" layout to create the MSI to bundle -->
2018-11-12 19:52:19 +00:00
<ItemGroup>
2019-12-20 21:13:26 +00:00
<SdkInternalFiles Include="$(RedistLayoutPath)sdk/$(Version)/**/*.*"/>
2018-11-12 19:52:19 +00:00
</ItemGroup>
<Copy SourceFiles="@(SdkInternalFiles)"
2019-12-20 21:13:26 +00:00
DestinationFiles="@(SdkInternalFiles -> '$(SdkInternalLayoutPath)sdk\$(Version)\%(RecursiveDir)%(Filename)%(Extension)')"/>
2018-11-12 19:52:19 +00:00
2018-10-24 01:16:45 +00:00
</Target>
</Project>