Support updating an extension to more specific target platform version

[Colengms]

We just published 1.8.1 (prerelease) of the C/C++ extension to the marketplace. I watched my local VS Code instance pick up the updated version, which promptly failed to execute properly. I noticed the following within it's .vsixmanifest:

<Identity Language="en-US" Id="cpptools" Version="1.8.1" Publisher="ms-vscode" TargetPlatform="win32-arm64"/>

This was on x64 Windows 11, yet the ARM64 VSIX was installed.

I actually encountered what was undoubtedly the same issue the last time we published, but was unable to reproduce it. It looks like the marketplace is updating clients to mismatching platform-specific VSIX's if the matching VSIX has not yet completed 'validation'. This issue only occurs for a brief window of time after we publish our VSIX's. But, I believe any user encountering this issue will need to delete the extension from their system (as Uninstall and reinstalling will reuse the cached extension folder).

---

Version: 1.63.2 (user setup)
Commit: 899d46d
Date: 2021-12-15T09:40:02.816Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.22000

[sandy081]

Irrespective of MP validation, VS Code should not allow installing win32-arm64 vsix on win32-x64 platform. I will investigate.

[Colengms]

This may be a separate issue, but it also seems to involve choosing the wrong platform-specific extension from the marketplace. When I try to 'install another version' of the C/C++ extension in a Remote WSL workspace, I get the following error:

[sandy081]

@Colengms

When you said you noticed different target platform property in.vsixmanifest is it in the vsix downloaded by VS Code? If so, may I know the name of the VSIX? We generally have the target platform in the name of the vsix.

[Colengms]

@sandy081 This is with the C/C++ Extension. We also include the name of the platform in the VSIX name, so in this case I was expecting cpptools-win64.vsix and received cpptools-win-arm64.vsix. However, I did not see the name of the downloaded VSIX itself, only the uncompressed contents in the extensions directory (including its .vsixmanifest), as it was downloaded and installed (upgraded to) by VS Code itself, not me. (That is the bug).

As we publish (updates for) each of our platform-specific VSIX's (with separate command lines), there is a window of time in which the marketplace is "validating" each one, during which time VS Code appears to download and install (upgrade to) an incorrect VSIX, undoubtedly because it incorrectly identifies an update (for another platform) while the updated VSIX for the appropriate platform was still in "Validating" state.

Not sure how much more info I can give. To reproduce the issue, it's necessary to publish a new version of multiple platform-specific VSIXs (of equal versions) to the marketplace and reload VS Code while some VSIX's are still indicated as "Validating" on the marketplace web site. This reproduces auto-update to an incorrect VSIX each time that we do this.

[sandy081]

@Colengms I am bit confused because, even though MP provides win32-arm64 vsix VS Code does not install it on win32-x64 platform, because it fails the compatibility check. I confirmed this behavior by having a test extension that supports win32-x64 and win32-arm64 platforms and publishing an update only for win32-arm64 platform. Hence I am wondering if VS Code is really installing win32-arm64 vsix on win32-x64 platform or the MP is returning it wrongly. If you are able to reproduce, can you please help me in providing following information?

• Open CachedExtensionVSIXs folder and remove all VSIXs - You can find this folder in the parent folder of your user settings file.
• Open Shared Process Developer Tools (F1 > Toggle Shared Process) and go to network tab
• Try to reproduce the issue
• In the network tab, share the URLs used to download the VSIX from the MP. For eg: https://sandy081.gallerycdn.vsassets.io/extensions/sandy081/999-pse-win/0.0.1/1631284756630/Microsoft.VisualStudio.Code.Manifest?targetPlatform=win32-x64
• Share the name of the VSIX downloaded in CachedExtensionVSIXs folder

[Colengms]

Hi @sandy081. I've repro'ed this multiple times. Once we publish our next version, I can possibly repro it again by upgrading (reloading the window) right after we publish, but it's a matter of getting the timing right (or wrong). I can assure you that there is an issue here. At no point did I attempt to install an arm64 VSIX on this x64 machine. As I mentioned, that incorrect TargetPlatform content was present in the .vsixmanifest in the installed extension directory, which indicates that the wrong VSIX was extracted.

We have added an error message that will be displayed to users when the wrong VSIX gets installed. I suspect we will get confirmation of this issue from users (if their timing is unfortunate) - possibly a small number of users each time we release an update. We will route those users to this issue for further investigation.