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.

[Colengms]

On my x64 Windows PC, running VS Code Insidesr 1.65.0, I repro'ed and had the following URL associated with the download:

https://ms-vscode.gallerycdn.vsassets.io/extensions/ms-vscode/cpptools/1.9.1/1645748050823/Microsoft.VisualStudio.Code.Manifest?targetPlatform=win32-ia32

Copied 'as fetch' from the Network tab

fetch("https://az764295.vo.msecnd.net/extensions/marketplace.json", { "referrer": "", "referrerPolicy": "strict-origin-when-cross-origin", "body": null, "method": "GET" }); ; fetch("https://ms-vscode.gallerycdn.vsassets.io/extensions/ms-vscode/cpptools/1.9.1/1645748050823/Microsoft.VisualStudio.Code.Manifest?targetPlatform=win32-ia32", { "headers": { "accept": "*/*", "accept-language": "en-US", "sec-fetch-dest": "empty", "sec-fetch-mode": "cors", "sec-fetch-site": "cross-site", "x-market-client-id": "VSCode 1.65.0-insider", "x-market-user-id": "6e1f7a87-d4bd-433d-8877-5978ce101a77" }, "referrerPolicy": "strict-origin-when-cross-origin", "body": null, "method": "GET" }); ; fetch("https://ms-vscode.gallerycdn.vsassets.io/extensions/ms-vscode/cpptools/1.9.1/1645748050823/Microsoft.VisualStudio.Code.Manifest?targetPlatform=win32-ia32", { "headers": { "accept": "*/*", "accept-language": "en-US", "sec-fetch-dest": "empty", "sec-fetch-mode": "cors", "sec-fetch-site": "cross-site", "x-market-client-id": "VSCode 1.65.0-insider", "x-market-user-id": "6e1f7a87-d4bd-433d-8877-5978ce101a77" }, "referrerPolicy": "strict-origin-when-cross-origin", "body": null, "method": "OPTIONS" }); ; fetch("https://ms-vscode.gallery.vsassets.io/_apis/public/gallery/publisher/ms-vscode/extension/cpptools/1.9.1/assetbyname/Microsoft.VisualStudio.Services.VSIXPackage?redirect=true&targetPlatform=win32-ia32&update=true", { "headers": { "accept": "*/*", "accept-language": "en-US", "sec-fetch-dest": "empty", "sec-fetch-mode": "cors", "sec-fetch-site": "cross-site", "x-market-client-id": "VSCode 1.65.0-insider", "x-market-user-id": "6e1f7a87-d4bd-433d-8877-5978ce101a77" }, "referrerPolicy": "strict-origin-when-cross-origin", "body": null, "method": "GET" }); ; fetch("https://ms-vscode.gallery.vsassets.io/_apis/public/gallery/publisher/ms-vscode/extension/cpptools/1.9.1/assetbyname/Microsoft.VisualStudio.Services.VSIXPackage?redirect=true&targetPlatform=win32-ia32&update=true", { "headers": { "accept": "*/*", "accept-language": "en-US", "sec-fetch-dest": "empty", "sec-fetch-mode": "cors", "sec-fetch-site": "cross-site", "x-market-client-id": "VSCode 1.65.0-insider", "x-market-user-id": "6e1f7a87-d4bd-433d-8877-5978ce101a77" }, "referrerPolicy": "strict-origin-when-cross-origin", "body": null, "method": "OPTIONS" }); ; fetch("https://ms-vscode.gallerycdn.vsassets.io/extensions/ms-vscode/cpptools/1.9.1/1645748050823/Microsoft.VisualStudio.Services.VSIXPackage", { "headers": { "accept": "*/*", "accept-language": "en-US", "sec-fetch-dest": "empty", "sec-fetch-mode": "cors", "sec-fetch-site": "cross-site", "x-market-client-id": "VSCode 1.65.0-insider", "x-market-user-id": "6e1f7a87-d4bd-433d-8877-5978ce101a77" }, "referrerPolicy": "strict-origin-when-cross-origin", "body": null, "method": "GET" }); ; fetch("https://ms-vscode.gallerycdn.vsassets.io/extensions/ms-vscode/cpptools/1.9.1/1645748050823/Microsoft.VisualStudio.Services.VSIXPackage", { "headers": { "accept": "*/*", "accept-language": "en-US", "sec-fetch-dest": "empty", "sec-fetch-mode": "cors", "sec-fetch-site": "cross-site", "x-market-client-id": "VSCode 1.65.0-insider", "x-market-user-id": "6e1f7a87-d4bd-433d-8877-5978ce101a77" }, "referrerPolicy": "strict-origin-when-cross-origin", "body": null, "method": "OPTIONS" }); ; fetch("https://az764295.vo.msecnd.net/extensions/marketplace.json", { "referrer": "", "referrerPolicy": "strict-origin-when-cross-origin", "body": null, "method": "GET" }); ; fetch("https://az764295.vo.msecnd.net/extensions/marketplace.json", { "referrer": "", "referrerPolicy": "strict-origin-when-cross-origin", "body": null, "method": "GET" }); ; fetch("https://az764295.vo.msecnd.net/extensions/marketplace.json", { "referrer": "", "referrerPolicy": "strict-origin-when-cross-origin", "body": null, "method": "GET" });

The cached VSIX was titled: ms-vscode.cpptools-1.9.1-win32-ia32

In this case, I was expecting our x64 build, not the x86 one (although it was compatible, in this case, as x86 runs on x64).

I repro'ed a similar issue on an ARM64 Windows PC. It downloaded the same x86 VSIX instead of the ARM64 one. I suspect our x86 VSIX completed 'validation' prior to the other VSIX's,

[sean-mcmanus]

I reproed the bug on Windows arm64 (latest Insiders, 1.65.0). CachedExtensionsVSIX has ms-vscode.cpptools-1.9.1-win32-ia32, url is "https://ms-vscode.gallerycdn.vsassets.io/extensions/ms-vscode/cpptools/1.9.1/1645748050823/Microsoft.VisualStudio.Code.Manifest?targetPlatform=win32-ia32". The expected result is win32-arm64. (Windows x64 didn't repro for me, i.e. it was correct)

[sandy081]

@Colengms and @sean-mcmanus Thanks for sharing the information. It seems VS Code is installing

• win32-ia32 vsix on win32-x64 platform
• win32-ia32 vsix on win32-arm64 platform

This can be totally possible and I have to say VS Code is doing right thing here. As @Colengms said MP is returning available target platforms as soon as they are available.

@joaomoreno @prashantvc @SaiKanth007 @isidorn

I think we discussed this concern and I do not remember the outcome or recommendation we ended upon. To summarise, C++ extension is publishing platform specific extension for each target using CI (I suppose). It seems win32-ia32 target VSIX is being published & validated & available first and when user is on win32-x64 or win32-arm64 platforms, this VSIX is getting installed/updated.

• Does MP has to stream line this and make them available all at once?
• Shall we recommend extension authors to publish win32-ia32 vsix at the end?

@Colengms One thing which is not clear for me is following scenario

• VS Code installing win32-arm64 vsix on win32-x64 platform

Meanwhile we discuss about first problem, can you please confirm if you are seeing the second problem and if so please share the logs as I requested.

Thanks

[isidorn]

@sandy081 I think it would hard for the MP to figure out how long to wait until to make them all available at once.

Is the only corner case win32-ia32 or can this happen in other cases as well?
If this is the only corner case, then we can do a "tactical fix" in vsce that we always upload that one last.

[sean-mcmanus]

We didn't repro the arm64 on x64 bug this time.

We can change our release pipeline to publish in order arm64 -> x64 -> x86 to see if that fixes it.

[Colengms]

@sandy081 @isidorn I think it would be fairly straightforward for you to create a repro of this without our assistance (so we do not have to tie the investigation of this issue with the releases of the C/C++ extension). I believe it's entirely coincidental that the win32-ia32 build completed validation first this time around and deployed to mismatching platforms. When we previously released, it was the win32-arm64 build that was deployed to my x64 machine, which is clearly incompatible.

I don't understand how it could not be an issue that platform-specific (emphasis on specific) VSIXs are deployed to platforms that do not specifically match the VSIX. It would seem implicit these should match exactly, regardless of whether or not the VSIX happens to also be compatible (to a potentially lesser extent) with the target system. IMHO, the correct behavior here would be for VS Code to not update the extension on any platform/architecture using any VSIX that was not an exact match for that system. If a more recent version is seen, but there is no match for the current platform/architecture, don't update (yet).

[sean-mcmanus]

@Colengms I'm guessing some extensions may not build an "exact" match vsix, but it seems like VS Code could check the current version's platform to determine that (i.e. if the current version is arm64 don't update to x64).

[Colengms]

The documentaton here states:

When publishing platform-specific extensions, a separate package needs to be published for each and every platform that an extension supports. If no package has been published for a platform, the user will see the extension appear as disabled and it can not be installed.

And goes on to define 'platforms' as os/architecture pairs.

---

If it is not an issue when compatible but mismatching versions of VSIXs are installed, could someone point me to how that compatibility is determined? We need similar logic for displaying an error (or warning) when the VSIX does not match or is incompatible.

x64 emulation on arm64 is available only on (a certain minimum version of) Windows 11, and not Windows 10. Currently, I'm using semver.gte(os.release(), "10.0.22000"), but that does not take into consideration versions prior to support being added.

On macOS, x64 can be emulated on arm64 only if the emulation components are installed. Do you do a check for x64 emulation in order to allow x64 builds to deploy on arm64 macOS?

Whether or not x64 or x86 is supported on Linux is complicated, due to arbitrary combinations of 32 and 64 bits userlands and kernels. Have you devised a check for this such that x86 VSIXs can be deployed to x64 Linux systems?

Intentionally supporting non-matching but compatible VSIX auto-updating is actually rather complex on all OSes. IMHO, it would seem a lot less problematic to require that platform-specific VSIX's match platforms exactly (as the documentation implies). Or, perhaps allow multiple platforms to be specified in the same VSIX.

[sandy081]

@Colengms I understand your concerns and it seems we are a bit off sync here. It might be because I did not mention fallbacks clearly. Sorry about that.

VS Code has fallback mechanisms for only following platforms.

• win32-x64 and win32-arm64 platforms are compatible with win32-ia32 vsix

If VS Code does not detect a specific VSIX for win32-x64 and win32-arm64 platforms it fallback to win32-ia32 vsix.

I could not repro the scenario that VS Code is installing win32-arm64 vsix on win32-x64 platform. Hence asked for more information from c++ extension as you are able to reproduce it.

@sean-mcmanus 's proposal to update extension only if it matches the existing platform seems to be reasonable but might cause inconsistencies - supporting fallback while installing and not while updating. Imagine an extension going forward will only have fallback vsix then VS Code will not update that extension.

Instead how about VS Code updates to specific target platform VSIX (even from fallback platform on same version) when available?

How about following action items:

• VS Code update the docs to mention about fallback platforms
• VS Code update the docs recommending the sequence of publishing VSIXs
• VS Code updates to specific platform VSIX if available (even when current version is same as latest version but on a fallback platform)
• C++ changes the publishing to recommended sequence

[sean-mcmanus]

That seems fine to me...we can try it out for our next release in a day or so.

[sandy081]

@isidorn Can you please update the platform specific extension publishing docs about this?

[isidorn]

@sandy081 sure, I will update the docs. I do not want to make the docs too complex, so I will try to summarise this in one-two sentences. Thanks for tackling this.

[isidorn]

Covered via microsoft/vscode-docs@77e247e