Code change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version: Steps to Reproduce:
Our C/C++ team has verified that our extension is correctly published to the marketplace with the correct binary -- our guess is that there is some VS Code or marketplace bug that is causing the wrong vsix to sometimes be installed.
Users are able to download/install our vsix manually from or so the bug appears to be with VS Code and/or the Remote WSL extension.
can you reproduce this problem? If yes can you file a new issue with reproducable steps? The issue is not 100% clear to us from this description. Thank you
Our C/C++ team has not been able to reproduce the problem yet. I'm guessing there's some random or unusual requirement, maybe involving a previously cached installation when an upgrade from version 1.9.8 to 1.10.5 of our extension occurs. I'm not familiar with what sort of install logging would be important for users who repro it to get, which is why I was thinking the issue should be tracked by VS Code (or the Remote extension or marketplace) and not our team. I'm aware of 4 user reports -- there could be more reported against VS Code that I'm not aware of. We don't believe our extension's warning about the incorrect binary is the root issue, and just a symptom of some other system downloading the incorrect vsix for the user's OS (we ship 10 different vsix's).
If you can let us know what the remote OS is and what the TargetPlatform property is set to in the file that could help us identify the problem.
yes getting more details here would be helpful. If you get a chance to repro the problem do let us know. Appreciate it!
A user reports that our .vsixmanifest file shows TargetPlatform="win32-x64" on a Linux-x64 remote machine (with Win-x64 host), which indicates that VS Code or the Remote extension or marketplace is somehow causing a download/install of the host platform's vsix instead of the remote one. I'm not familiar with what the next steps are in terms of diagnostics, but it seems like at least there should be an open VS Code (or Remote extension) bug to track this, since currently there are just 4 or so closed issues. See
I'm the reporter of This is not the case for me as I have installed the C/C++ extension for the first time. I don't usually use VS Code but just tried it to reproduce another problem reported by a user. Also, as far as I remember, this is the first time for me to connect to a remote workspace using VS Code. Something that might be related is the version of VS Code. I think I have originally installed VS Code back in October 2021. After that, I hadn't updated the VS Code for a long time because I'm not using it. This time, I think I first tried to install the C/C++ extension with the old version of VS Code and failed. After that, I updated VS Code to the latest version from the main menu of the VS Code, which didn't solve the problem. I'm not sure if this is really related, but is it unsupported to update VS Code from an old version (8-month old) in a single update (i.e., without any intermediate versions)? For example, some migration steps to update the cache or database format would be skipped? We might be able to ask other reporters about their situations? (), (), (this issue): How's the situation? Did you experience the problem in the remote workspace such as in WSL? Have you recently updated VS Code? When have you updated VS Code previously?
I am using the VS code(version 1.67) in Ubuntu 16.04 LTS (64 bit OS) which is hosted VM in Oracle VM virtual box. While trying to install C/C++ extension in the VS code, it was not proceeding and VS code suggested to download it from the website and install it via vsix. So, I have done the same. The installation of extension was successful but later during debugging, it has mentioned that wrong/incompatible binaries. please let me know if anymore information is required.
I was not using remote workspace WSL. I am just trying to use VS code for client side code at my local VM.
cc
Your issue might be different? You installed the Linux x64 vsix, right? What is the TargetPlatform property set to in the .vscode[-insiders]/extensions/ms-vscode.cpptools-[version][os-description]/.vsixmanifest file? It should say "linux-x64". What version of the C/C++ extension are you installing? Our team is able to debug with the Linux x64 vsix so we don't know what could be going wrong yet.
Sorry that I am late to the party. It would be great if I can get summary of the issue? Does it happen to be reproducible?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
I have been thinking that you have checked the linked issues, but let me comment in case you haven't noticed them. I have already described the details about my situation in my initial report If needed, I can just copy and paste the comment to here. Nevertheless, I can answer additional questions about my situation if any. We may also find some information by the OP of this issue in
May I know if you have downloaded the VSIX that is compatible to the platform you are using? !
It's not me. The above comment is from In my case, I initially tried to install the extension from a VS Code client in Win 10 opened for the remote workspace (Ubuntu 20.04 / WSL2), which fails with the message of incompatible binaries. After the suggestion in , I have downloaded the VSIX from and installed it in the remote, which was successful unlike the case of I'm not sure which version has downloaded. !
The problem is, as I have reported in , VS Code seems to wrongly download the VSIX of in Ubuntu 20.04/WSL2 instead of the VSIX of . I have tried several times VS Code's install button with different configurations for both VS Code and VS Code Insiders, but all failed in the same way.
Got it. Thanks for update. Can you please share us with a gif/video of what you are doing so that we can understand more about the issue? Can you please share us with the following logs after reproducing the issue? F1 Open View... Log (Window) F1 Open View... Log (Remote)
I tried to upload it to here but couldn't do it due to the size limit. I have instead uploaded it to YouTube: Log (Window) I cannot find such a view. Instead, I see and : Log (Remote Server) Log (Remote Extension Host)
Which version of VS Code are you using? Instead of downloading from the installed section, can you please try searching for the extension, say by typing c++ in the search input and install? Does it work if you uninstall the extension and install again?
As I have reported in , I have confirmed the behavior in and . Further details are found in As it does not seem to reproduce in every environment, I guess some other factors in my environment causes the problem.
I now noticed these additional comments. I'll try them when I get back home.
This installs the correct version of the extension. What is the correct way to uninstall the extension from the remote? (a) As explained in , I have already tried many times removing the remote extension---by deleting the directory as suggested in ---and installing it again. But they didn't change anything.(b) When I select the C/C++ extension from the installed section and press the [Unintall] button (see below), the remote extension is still located under , but the local extension instead seems to be uninstalled. ! (c) Also, when I type in the search input, select the C/C++ extension, and press the [Uninstall] button (see below), the remote extension is still there, and the local extension is instead uninstalled. !
So it means you are getting incompatible C++ extension when you use the button ? In both above screenshots, pressing Uninstall will uninstall locally as the extension seems to be installed locally. So, please try pressing uninstall button and install the extension again?
Yes. I had already tried that many times. The result doesn't change; It again installs an incompatible version as far as I use the button .
Can you please provide following logs while trying this? Enable log level to trace - F1 Set Log Level Share F1 Open View... Log (Remote) Share F1 Open View... Log (Window)
Here, I attach the logs: This time, (1) I first attempted to install the extension by pressing . (2) Then reopen the extension page, press and reloaded the VS Code. (3) Then, I again attempted to install the extension from the button. In the zip archive, the following files are included: --- This includes the log of in step (1) described above. --- This includes the log of in step (1). --- This includes the log of in step (3). --- This includes the log of in step (3). --- This includes the log of in step (3).
Thanks for the logs and I think I know the root cause of this issue. It seems in your case the extension is being copied from local client (Windows) to remote (WSL) and hence the bits are being incompatible. This happens if VS Code cannot find a matching installed extension in the Marketplace. In this case, VS Code falls back to copy the extension. Fixed it as follows: Before using the fallback to copy Try again to get the matching extension from the Marketplace In the fallback check if the local extension is compatible with the remote platform. This fix does not covers if you have manually installed an extension that does not exist in the Marketplace and is platform specific.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!

Related discussion:
text: @IExtensionsWorkbenchService extensionsWorkbenchService: IExtensionsWorkbenchService, @IExtensionManagementServerService extensionManagementServerService: IExtensionManagementServerService, @IExtensionManifestPropertiesService extensionManifestPropertiesService: IExtensionManifestPropertiesService, <ins> @IExtensionGalleryService extensionGalleryService: IExtensionGalleryService, </ins> ) { <del> super(`extensions.localinstall`, extensionManagementServerService.localExtensionManagementServer, false, extensionsWorkbenchService, extensionManagementServerService, extensionManifestPropertiesService); </del> <ins> super(`extensions.localinstall`, extensionManagementServerService.localExtensionManagementServer, false, extensionsWorkbenchService, extensionManagementServerService, extensionManifestPropertiesService, extensionGalleryService); </ins> } protected getInstallLabel(): string {