Missing Microsoft.Windows.UI.Xaml.CSharp.targets from VS2022 BuildTools image about dotnet-framework-docker

[mthalman]

Ok sure, there's a possibility of things being out of sync for a short period. There's not a way to account for that since VS doesn't provide channel URLs for every version, only LTS and Current.

[microsoft-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[richlander]

This looks like it is a question of which workloads we are installing and how much bigger the SDK image would grow to support that workload. I'm worried it would be significant. If it's large, we should make a policy that these images are targeted at web workloads only.

[mthalman]

I looked up the available Build Tools workloads at https://docs.microsoft.com/visualstudio/install/workload-component-id-vs-build-tools?view=vs-2022

The Microsoft.VisualStudio.Workload.UniversalBuildTools workload comes with all these components:

Microsoft.Component.MSBuild
Microsoft.Component.NetFX.Native
Microsoft.Net.Component.4.8.SDK
Microsoft.NetCore.Component.Runtime.6.0
Microsoft.NetCore.Component.SDK
Microsoft.VisualStudio.Component.NuGet.BuildTools
Microsoft.VisualStudio.Component.Roslyn.Compiler
Microsoft.VisualStudio.ComponentGroup.UWP.BuildTools
Microsoft.VisualStudio.Component.Windows10SDK.19041
Component.Microsoft.Windows.CppWinRT
Microsoft.Net.Component.4.7.2.SDK
Microsoft.VisualStudio.Component.UWP.VC.ARM64
Microsoft.VisualStudio.Component.UWP.VC.ARM64EC
Microsoft.VisualStudio.Component.VC.14.29.16.11.ARM64
Microsoft.VisualStudio.Component.VC.CoreBuildTools
Microsoft.VisualStudio.Component.VC.Tools.ARM
Microsoft.VisualStudio.Component.VC.Tools.ARM64
Microsoft.VisualStudio.Component.VC.Tools.ARM64EC
Microsoft.VisualStudio.Component.VC.Tools.x86.x64
Microsoft.VisualStudio.Component.VC.v141.ARM
Microsoft.VisualStudio.Component.VC.v141.ARM64
Microsoft.VisualStudio.Component.VC.v141.x86.x64
Microsoft.VisualStudio.Component.Windows10SDK
Microsoft.VisualStudio.Component.Windows10SDK.18362
Microsoft.VisualStudio.Component.Windows11SDK.22000
Microsoft.VisualStudio.ComponentGroup.UWP.VC.BuildTools
Microsoft.VisualStudio.ComponentGroup.UWP.VC.v141.BuildTools
Microsoft.VisualStudio.ComponentGroup.UWP.VC.v142.BuildTools
Microsoft.VisualStudio.ComponentGroup.VC.Tools.142.x86.x64

That's a lot. There's a lot of C++ stuff in there too. But the Microsoft.VisualStudio.ComponentGroup.UWP.BuildTools individual component seemed promising. So I tested this by including that component in the list of components we install here:

dotnet-framework-docker/src/sdk/4.8/windowsservercore-ltsc2022/Dockerfile

Lines 31 to 41 in 935817b

	&& start /w vs_BuildTools ^ `
	--add Microsoft.Component.ClickOnce.MSBuild ^ `
	--add Microsoft.Net.Component.4.8.SDK ^ `
	--add Microsoft.NetCore.Component.Runtime.3.1 ^ `
	--add Microsoft.NetCore.Component.Runtime.5.0 ^ `
	--add Microsoft.NetCore.Component.Runtime.6.0 ^ `
	--add Microsoft.NetCore.Component.SDK ^ `
	--add Microsoft.VisualStudio.Component.NuGet.BuildTools ^ `
	--add Microsoft.VisualStudio.Component.WebDeploy ^ `
	--add Microsoft.VisualStudio.Web.BuildTools.ComponentGroup ^ `
	--add Microsoft.VisualStudio.Workload.MSBuildTools ^ `

That ended up increasing the image size by about 10 GB, just for that component. That seems prohibitive to including in the sdk image by default.

[mthalman]

The way to add this component yourself on top of the sdk image is the following:

FROM mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-ltsc2019

RUN curl -SL --output vs_buildtools.exe https://aka.ms/vs/17/release/vs_buildtools.exe && \
    (start /w vs_buildtools.exe --quiet --wait --norestart --nocache modify \
    --installPath "%ProgramFiles(x86)%\Microsoft Visual Studio\2022\BuildTools" \
    --add Microsoft.VisualStudio.ComponentGroup.UWP.BuildTools) && \
    del /q vs_buildtools.exe

[rainersigwald]

I think documenting that is likely sufficient (though I'm just passing the customer feedback along here), but is there a problem with tearing the version of vs_buildtools.exe against the base image?

[mthalman]

but is there a problem with tearing the version of vs_buildtools.exe against the base image?

Are you referring to the fact that the version is hardcoded?

[rainersigwald]

I'm thinking "user runs their image build between VS updating the destination of https://aka.ms/vs/17/release/vs_buildtools.exe and an updated mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-ltsc2019 being based on that".

[rainersigwald]

Only way out I can think of is "leave the installer in the official image, bloating its size but allowing it to be run again". Which may not be worth it.

[mthalman]

Yeah, and I don't even know how you do that. The exe that we're downloading directly is only the bootstrapper. The bootstrapper is not tied to a specific VS version. Not until the bootstrapper automatically downloads whatever it downloads when you run the install do you actually have something specific to the VS version. And I don't know if there's even a way to cause that to be downloaded without actually running an install.

[mthalman]

[Triage]
Given the large install size (10 GB) of the component and that this is not a primary scenario for the .NET Framework SDK image, we'll not be including this component in the image. Instead, you can follow the guidance for installing the component yourself on top of the sdk image.

[mthalman]

[Triage]
Given the large install size (10 GB) of the component and that this is not a primary scenario for the .NET Framework SDK image, we'll not be including this component in the image. Instead, you can follow the guidance for installing the component yourself on top of the sdk image.

[DynConcepts]

Ok sure, there's a possibility of things being out of sync for a short period. There's not a way to account for that since VS doesn't provide channel URLs for every version, only LTS and Current.
@mthalman -- OK, now (almost April 2024 -- over 1.5 years - is that a "Short period"?

Seriously.. Have VS-2022 17.8.4 with the UWP workload installed and that Targets file is STILL missing....