visualstudio2022buildtools Fails to Install - Version Mismatch?

[eXpl0it3r]

Thanks a lot for maintaining this package!

When I run the following install command it fails to install with the following error:

choco install visualstudio2022buildtools \
  --x86 \
  --confirm \
  --ignore-package-exit-codes \
  --limit-output \
  --timeout 21600 \

visualstudio2022buildtools has been installed.
ERROR: After update operation, Visual Studio product: [installPath = 'C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools'] is at version 17.3.32804.467, which is lower than the desired version (17.3.32811.315). This means the update failed.
The install of visualstudio2022buildtools was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\visualstudio2022buildtools\tools\ChocolateyInstall.ps1'.
 See log for details.

I don't fully understand where the "desired version" comes from and why it's apparently higher than the actually installed version.

Is there a workaround for this?

[jberezanski]

This check should only be relevant in an upgrade scenario (if you already have an older VS 2022 Build Tools version installed and the package upgrades it to the latest).
The package reads the "desired version" from a manifest file (hosted by Microsoft at https://aka.ms/vs/17/release/channel), which drives the Visual Studio installation. For example, today it contains:

{"id":"Microsoft.VisualStudio.Product.BuildTools","version":"17.3.32819.101"

(which, according to VS release history, is "display version" 17.3.2)

The package always installs the latest published VS version and expects that the version detected on the machine after the setup process completes matches the version specified in the manifest file. If the version on the machine is lower, the package assumes the upgrade process has failed for some reason even though the VS install process did not return an error code (I have seen it happen in various cases, in particular with older versions of the VS Installer; it was caused by the VS Installer failing to download the current manifest file and thinking no update was needed).

Now, there is a complication, regarding very minor VS updates. But first, please confirm: did you actually have Build Tools installed on the system before invoking that choco install command? Additionally, can you share your choco log file (C:\ProgramData\Chocolatey\logs\chocolatey.log)?

[jberezanski]

I might as well describe the complication already:
There have been cases of VS updates so tiny/focused that they would not touch any components present in Build Tools. I have seen it in VS 2017 some months ago, I don't recall the specific versions. The official VS version was increased and all products (Professional, Enterprise, Build Tools etc.) got updated install links, but existing installations of previous version of Build Tools would not update to the newly released version - the installation would succeed, but the reported installed version would not change. In contrast, a new installation of Build Tools would get the newer version number.

This, in fact, seems to be what has happened recently in VS 2022. Version 17.3.1 exibits the same behavior:

• installing Build Tools 2022 17.3.1 (using its fixed version installer from the release history) results in version 17.3.1 being reported as installed
• upgrading Build Tools from 17.3.0 using the 17.3.1 installer succeeds, but does not increment the version number

Fortunately, 17.3.2 (released yesterday) behaves reasonably and does update the Build Tools. So you should no longer encounter the problem.

[eXpl0it3r]

Thanks a lot for the response!

I'm building a docker image, but I'm actually not a 100% sure what the base image is already shipping with.
The reason I encounter this was mainly because I need the visualstudio2022-workload-databuildtools package that has a dependency onto visualstudio2022buildtools. As it kept failing, I added an explicit step for visualstudio2022buildtools which kept failing with the mentioned errors.

But if the base image already ships with the build tools, then your explanation can totally make sense. Wonder if there's a workaround for this issue though, as it kind of breaks the installation process.

---

Just test the installation process again and this time it succeeded, as such it's even more of an indication that it was caused by the "complication". 😄

Unfortunately I don't have the log, as I've removed the "failed" docker image build.

From my point of view the issue can be closed, unless you want to keep it open to discuss potential solutions for the "complication".

[jberezanski]

I'm actually not a 100% sure what the base image is already shipping with

Are you using a publicly available base image? If yes, can you share the link?

As for inspecting the existing state, there are two easy ways:

1. turn on choco verbose and debug logging: choco install --verbose --debug ... (I'd also remove --limit-output) - the package will emit a lot of detailed diagnostic messages, in particular it will report if any VS products are already present

2. use the VSSetup PowerShell module:

Install-PackageProvider NuGet -Force
Install-Module VSSetup -Force
Get-VSSetupInstance | Format-List -Property *

---

Wonder if there's a workaround for this issue

The way the VS choco packages currently work is they always install (or upgrade to) the latest VS version published by MS (regardless of package version: you can run choco install visualstudio2022buildtools --version 117.0.0.0 and you will still get VS 17.3.2, as of today). This might be inconvenient if you are building an image, because you essentially do not have control over the exact contents of the image, so the build process is not repeatable and you may suddenly get different behavior.

There is, however, a way to reliably install a specific VS version. The scripts used internally in the packages support it already; I've been thinking about publishing such "deterministic" packages, but never had the time and sufficient motivation. But you can do this:

1. Pick the desired VS Build Tools version from the release history and copy the url for the fixed version bootstrapper from the Current channel (e.g. Build Tools 17.2.6)

2. In the dockerfile, download that bootstrapper and pass it to the choco package:

Invoke-WebRequest -UseBasicParsing -Uri 'https://download.visualstudio.microsoft.com/download/pr/91cf5cbb-c34a-4766-bff6-aea28265d815/645d56f3dc5b12783a0c9a19dc90a2cfc63191d837e6c988fba91e6db3525bf3/vs_BuildTools.exe' -OutFile .\vs_BuildTools-17.2.6.exe
choco install --confirm --verbose --debug visualstudio2022buildtools --version 117.2.6.0 --package-parameters "--bootstrapperPath .\vs_BuildTools-17.2.6.exe"

(the choco package version is set in this command only as a way of improving the repeatability of the image build; it does not affect the VS version being installed - the specific bootstrapper does that)

3. Now you have full control over the VS version in each image build and can decide exactly when you want to upgrade to a newer version. (You would probably also need to control the specific version of the base image to be used, so that it does not suddenly come with a newer Build Tools.)

---

By the way, the --x86 switch has no effect for VS packages. Visual Studio does not come in two bitness flavors.

---

From my point of view the issue can be closed, unless you want to keep it open to discuss potential solutions for the "complication".

Yes, I'll keep it open as a reminder. Previously, when I had seen the problem only in VS 2017, I didn't really feel the need to act upon it, but now that it has appeared in 2022 it might become a nuisance and require some action.

[Stiverton]

upgrading Build Tools from 17.3.0 using the 17.3.1 installer succeeds, but does not increment the version number

I'm having this problem right now again when upgrading from 17.8.0.0 to 17.8.1.0. Is there any kind of logic to what kind of build tools version increment will actually cause the component to receive an update? If so would it be possible to have the version match check be a little more lenient so that upgrades wont just error out when the succeed with Microsoft's expected behavior?

[jberezanski]

Is there any kind of logic to what kind of build tools version increment will actually cause the component to receive an update?

Unfortunately, I haven't been able to find any reliable source of that information, short of actually attempting the upgrade on a test machine and seeing what happens (and doing that for each new version is out of the question due to the workload and costs involved). Perhaps this is somehow buried in the channel manifest (https://aka.ms/vs/17/release/channel), or the component manifest referenced by it, but so far nothing stood out for me.

This whole problem seems to me like a bug/design flaw of the Visual Studio Installer, because if Build Tools is installed on a clean machine, it will have the correct (latest) version number. Only the upgrade process fails to update the version.

Now, approaching from another angle: the whole intent of the version check in the package scripts was to detect cases when the upgrade process failed. This is important when other packages depend on a minimum version of Visual Studio (such as some workload packages). However, I think it would be okay to change the version check to accomodate both needs: raise an error when the minor version (second part) is lower than expected, but tolerate a difference in the patch version (third part) and just log a warning.