Skip to content

Remove use of runtime -internal archives #27687

Closed
Closed
Remove use of runtime -internal archives#27687
Assignees
wtgodbe
Labels
DoneThis issue has been fixedaffected-very-fewThis issue impacts very few customersarea-infrastructureIncludes: MSBuild projects/targets, build scripts, CI, Installers and shared frameworkfeature-installersIncludes: Installersseverity-minorThis label is used by an internal tooltask
Milestone
6.0.0

Description

@mmitche
mmitche
opened on Nov 10, 2020

To bring source build and the Microsoft build in line, and reduce the overall size of the .NET build output (-internal archives correspond to about 1.3GB of in the total build drop), aspnetcore should remove using of the runtime -internal archives, instead using the customer archives and extracting the bits they need.

Activity

  1. mmitche
    changed the title [-]Remove using of runtime -internal archives[/-] [+]Remove use of runtime -internal archives[/+] on Nov 10, 2020

  2. mmitche commented on Nov 10, 2020

    @mmitche
    mmitche
    on Nov 10, 2020
    MemberAuthor

    See dotnet/installer#9042 for additional context.

  3. wtgodbe
    added
    area-infrastructureIncludes: MSBuild projects/targets, build scripts, CI, Installers and shared framework
    feature-installersIncludes: Installers
    on Nov 10, 2020
  4. wtgodbe
    added this to the 6.0.0 milestone on Nov 10, 2020

  5. dougbu commented on Nov 16, 2020

    @dougbu
    dougbu
    on Nov 16, 2020
    Contributor

    #27845 is failing because dotnet/runtime has stopped updating Microsoft.NETCore.App.Internal. But, is the version of Microsoft.NETCore.App.Runtime..win-x64 now guaranteed to be useful and correct in global.json❔ (Thought we had the .Internal package for a real reason.)

  6. mmitche commented on Nov 16, 2020

    @mmitche
    mmitche
    on Nov 16, 2020
    MemberAuthor

    #27737 is the right PR for this.

  7. wtgodbe
    added
    affected-very-fewThis issue impacts very few customers
    severity-minorThis label is used by an internal tool
    task
    on Dec 7, 2020
  8. wtgodbe
    self-assigned this
    on Jan 6, 2021

  9. wtgodbe commented on Jan 7, 2021

    @wtgodbe
    wtgodbe
    on Jan 7, 2021
    Member

    As far as I can tell, we don't download the -internal runtime archive at all - only the public one. Here are all of the references to it in the repo that I could find:

    aspnetcore/src/Framework/App.Runtime/src/Microsoft.AspNetCore.App.Runtime.csproj

    Lines 34 to 37 in 39c471a

    <DotNetRuntimeArchiveFileName>dotnet-runtime-$(MicrosoftNETCoreAppRuntimeVersion)-$(TargetRuntimeIdentifier)$(ArchiveExtension)</DotNetRuntimeArchiveFileName>
    <DotNetRuntimeDownloadUrl>$(DotNetAssetRootUrl)Runtime/$(MicrosoftNETCoreBrowserDebugHostTransportVersion)/$(DotNetRuntimeArchiveFileName)</DotNetRuntimeDownloadUrl>
    <DotNetRuntimePrivateDownloadUrl>$(DotNetPrivateAssetRootUrl)Runtime/$(MicrosoftNETCoreBrowserDebugHostTransportVersion)/$(DotNetRuntimeArchiveFileName)</DotNetRuntimePrivateDownloadUrl>
    <DotNetRuntimeArchive>$(BaseIntermediateOutputPath)$(DotNetRuntimeArchiveFileName)</DotNetRuntimeArchive>

    aspnetcore/src/Installers/Windows/WindowsHostingBundle/Product.targets

    Lines 31 to 46 in 39c471a

    <ItemGroup>
    <RemoteAsset Include="Runtime/$(MicrosoftNETCoreBrowserDebugHostTransportVersion)/dotnet-runtime-$(MicrosoftNETCoreAppRuntimeVersion)-win-x64.exe">
    <TargetFileName>dotnet-runtime-$(MicrosoftNETCoreAppRuntimeVersion)-win-x64.exe</TargetFileName>
    </RemoteAsset>
    <RemoteAsset Include="Runtime/$(MicrosoftNETCoreBrowserDebugHostTransportVersion)/dotnet-runtime-$(MicrosoftNETCoreAppRuntimeVersion)-win-x86.exe">
    <TargetFileName>dotnet-runtime-$(MicrosoftNETCoreAppRuntimeVersion)-win-x86.exe</TargetFileName>
    </RemoteAsset>
    </ItemGroup>
    <MakeDir Directories="$(DepsPath)" />
    <DownloadFile Condition=" ! Exists('$(DepsPath)%(RemoteAsset.TargetFileName)') "
    Uri="$(DotNetAssetRootUrl)%(RemoteAsset.Identity)"
    PrivateUri="$(DotNetPrivateAssetRootUrl)%(RemoteAsset.Identity)"
    PrivateUriSuffix="$(DotNetAssetRootAccessTokenSuffix)"
    DestinationPath="$(DepsPath)%(RemoteAsset.TargetFileName)" />

  10. wtgodbe
    closed this as completedon Jan 7, 2021
  11. wtgodbe
    added
    DoneThis issue has been fixed
    on Jan 7, 2021

  12. dougbu commented on Jan 7, 2021

    @dougbu
    dougbu
    on Jan 7, 2021
    Contributor

    Closing this was the Right Thing:tm: to do. This was fixed in 634b50e aka #27737; we now use $(MicrosoftNETCoreBrowserDebugHostTransportVersion) to get the correct non-stable version when downloading runtimes.

    Thanks again @jkoritzinsky❕

  13. ghost locked as resolved and limited conversation to collaborators on Feb 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

DoneThis issue has been fixedaffected-very-fewThis issue impacts very few customersarea-infrastructureIncludes: MSBuild projects/targets, build scripts, CI, Installers and shared frameworkfeature-installersIncludes: Installersseverity-minorThis label is used by an internal tooltask

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions