Missing Microsoft.Windows.UI.Xaml.CSharp.targets from VS2022 BuildTools image

[rainersigwald]

moved from https://developercommunity.visualstudio.com/t/Missing-MicrosoftWindowsUIXamlCSharp/10087402

[severity:I’m unable to use this version] Docker Image: mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-ltsc2019

When building, msbuild failed with the following message:

C:\source\Utilities\RetryCleanUpUtility\RetryCleanUpUtility.csproj(197,11): error MSB4226: The imported project "C:\Prog
ram Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Microsoft\WindowsXaml\v17.0\Microsoft.Windows.UI.Xaml.CS
harp.targets" was not found. Also, tried to find "Microsoft\WindowsXaml\v17.0\Microsoft.Windows.UI.Xaml.CSharp.targets"
in the fallback search path(s) for $(MSBuildExtensionsPath) - "C:\Program Files (x86)\MSBuild" . These search paths are
defined in "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\Bin\amd64\msbuild.exe.Config". 
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk in one of the search paths.

The failing project is a Universal Windows project.

How can I install the required workload?

[microsoft-issue-labeler[bot]]

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: https://github.com/microsoft/dotnet-framework-docker/blob/935817b4df76d13b04f274d1349ec0aefb377d1f/src/sdk/4.8/windowsservercore-ltsc2022/Dockerfile#L31-L41

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".

[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.

[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....