Add the .NET Framework v4.5 targeting pack windows.vs2022.amd64[.open] queue.

[andriipatsula]

• This issue is blocking
• This issue is causing unreasonable pain

Customer is requesting to add the NET Framework v4.5 targeting pack windows.vs2022.amd64[.open] queue. Original comment from the FR channel:

Could the .NET Framework v4.5 targeting pack please be added to agents in the windows.vs2022.amd64[.open] queues?There are v4.5.2 SDK and targeting pack components available for vs2022 but I am loath to change the TFMs even slightly in our packages (this is a legacy framework repo) unless that's absolutely mandatory. I'd leave us on the windows.vs2019.amd64[.open] queues if I didn't need to target net6.0 from desktop msbuild.

Release Note Category

• Feature changes/additions
• Bug fixes
• Internal Infrastructure Improvements

Release Note Description

[dougbu]

This issue is blocking aspnet/AspNetWebStack#384.

I should also say that eventually we'll need .NET v4.5.2 as well. I forgot about the code we have in TFS that'll be needed when we migrate our official builds to dnceng/internal. This addition might be easier to implement since it's available as a VS2022 component (Microsoft.Net.Component.4.5.2.TargetingPack).

[MattGal]

Action item: @dougbu and @joeloff will provide the installer they want made into a custom artifact; it seems to be difficult to find presently.

[dougbu]

The Teams discussion led us to either a Windows SDK (that includes the v4.5 targeting pack) or the VS2019 BuildTools installer w/ just the one component configured. Is that not palatable❔

I'm aware the question of which Windows SDK version might include v4.5 remains open in the Teams conversation. However, using that type of installer seems less focused (more prone to security issues) than using the VS installer. So, are there open questions here❔

Separately, please add the v4.5.2 targeting pack to the list of VS2022 components installed on these agents.

[MattGal]

I set up a meeting for today to discuss getting this done. The primary concern here is that a second build tools install of VS on a given image will nearly double image generation time for it forever; we'll chat about approaches that unblock the scenario and figure out which to do then.

[MattGal]

@dougbu per our previous call, I've verified that the following workloads are on our VS 2019 images:

"Microsoft.Net.Component.4.6.1.TargetingPack",
"Microsoft.Net.Component.4.7.2.TargetingPack",
"Microsoft.Net.Component.4.5.2.TargetingPack",
"Microsoft.Net.Component.4.5.TargetingPack",
"Microsoft.Net.Component.4.TargetingPack",
"Microsoft.Net.Component.4.5.1.TargetingPack",
"Microsoft.Net.Component.4.6.TargetingPack",
"Microsoft.Net.ComponentGroup.TargetingPacks.Common",
"Microsoft.Net.Component.4.6.2.TargetingPack",
"Microsoft.Net.Component.4.7.TargetingPack",
"Microsoft.Net.Component.4.7.1.TargetingPack",
"Microsoft.Net.Component.4.8.TargetingPack",

(includes 4.5.2!)

and prepared a standalone sample based off arcade/common functionality for getting Dev17-era MSBuild available on such a machine:

# Lifted from https://github.com/dotnet/arcade/blob/main/eng/common/tools.ps1

function Create-Directory ([string[]] $path) {
    New-Item -Path $path -Force -ItemType 'Directory' | Out-Null
}

function Unzip([string]$zipfile, [string]$outpath) {
  Add-Type -AssemblyName System.IO.Compression.FileSystem
  [System.IO.Compression.ZipFile]::ExtractToDirectory($zipfile, $outpath)
}

function InitializeXCopyMSBuild([string]$packageVersion, [bool]$install, [string]$ToolsDir) {
  $packageName = 'RoslynTools.MSBuild'
  $packageDir = Join-Path $ToolsDir "msbuild\$packageVersion"
  $packagePath = Join-Path $packageDir "$packageName.$packageVersion.nupkg"

  if (!(Test-Path $packageDir)) {
    if (!$install) {
      return $null
    }

    Create-Directory $packageDir

    Write-Host "Downloading $packageName $packageVersion"
    $ProgressPreference = 'SilentlyContinue' # Don't display the console progress UI - it's a huge perf hit
    Invoke-WebRequest "https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/flat2/$packageName/$packageVersion/$packageName.$packageVersion.nupkg" -OutFile $packagePath

    Unzip $packagePath $packageDir
  }

  return Join-Path $packageDir 'tools'
}


Write-Output "Here's an example of getting The Roslyn Tools Xcopy-able msbuild outside of arcade."
$basePath = InitializeXCopyMSBuild -packageVersion 17.4.1 -install $true -ToolsDir $PSScriptRoot
# Add it to the path... 
$env:Path = "$env:Path;$basePath\MSBuild\Current\Bin"

# Invoke it to show it's msbuild... 
msbuild --version

Can you please try this out and see if it can be used as a stopgap solution before arcade-ifying your repo?

[dougbu]

Can you please try this out and see if it can be used as a stopgap solution before arcade-ifying your repo?

I'll give it a shot 😁 Been focused on another negative aspect of my PR but will get back to this part tomorrow I hope.

nit: We may never fully Arcade-ify this repo. We haven't really looked closely at what's necessary and what will get us away from TeamCity the fastest. We'll definitely use some aspects e.g. pushing packages to the BAR but, generally, think of it as Arcade-iffy.

[dougbu]

aspnet/AspNetWebStack#384 built fine w/ @MattGal's suggested changes. No further action needed here.