Closed rainersigwald closed 2 years ago
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.
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.
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.
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
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?
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?
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".
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.
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.
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.
[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.
[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.
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....
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:
The failing project is a Universal Windows project.
How can I install the required workload?