Support pinning extension version when installed from CLI

[sandy081]

Follow up item from #12764

Do not trigger auto updates when a specific version of extension is installed from CLI

[sandy081]

This depends on availability of Storage Service in the cli process. @bpasero Let me know if it is feasible otherwise I would close it as a technical limitation.

[bpasero]

@sandy081 doable, see:

// Create
services.set(IStorageMainService, new SyncDescriptor(StorageMainService));

// Init
this.storageMainService.initialize()

// Close
this.lifecycleService.onWillShutdown(e => e.join(storageMainService.close()));

[bpasero]

If main is already running there is a small chance that you see an error when reading items because the DB is in use. I assume you are not writing values right?

[sandy081]

I have to write into storage to ignore auto updating an extension.

[bpasero]

@sandy081 got it. In that case I would suggest to:

• write into storage if CLI is the only process running
• otherwise ask the main process to do that

Reading should be fine from the CLI in either cases.

[sandy081]

Cool, Is there a way to check if cli is the only process running?

[bpasero]

@sandy081 maybe @joaomoreno knows

[joaomoreno]

When main starts up, the first thing it tries to create a socket for IPC. If it fails with EADDRINUSE, it means another main is already running, so it tries to connect to the existing main instance. This is how we make sure only one main runs, yet follow up mains send argv to that initial instance and we're able to open files on that initial instance.

CLI needs to join in on this dance. It should try to connect to that IPC channel. If successful, it should just tell that main what it should do. Else, it should do it itself, as quickly as possible.

[Falconne]

It seems that now, even if you install a specific older version via the GUI with "Install Another Version ...", VS Code will immediately auto update the extension to the latest version after a reload. Based on #12764 I assume this is a regression.

I noticed this when I tried to rollback the PowerShell extension as the latest version broke auto-formatting.

I don't know if I should open a new issue for that as this functionality seems to be universally broken now and not just CLI specific, but figured I'd comment here first.

[sandy081]

@Falconne Yeah it was broken and fixed it in insiders.

[lovette]

I'm surprised this issue doesn't have more activity. I'm running into a related issue today.

The latest ms-python extension no longer supports Python 2.7 so I need to ensure an older version of the extension is installed when I attach to some remote containers. As it stands, Code installs the latest Python extension (as well as the Jupyter extension, which I never use and cannot find a way to disable.) I then have to downgrade ms-python, uninstall ms-toolsai.jupyter and relaunch the connection. (At this point a node process more often than not goes ballistic and eats up all the CPU until the container itself is restarted.) I wish I could simply include ms-python.python-2022.2.1924087327 in the extensions list of the named container settings .json.

(Note that I'm using Remote-SSH to connect to a remote host then using Remote-Containers to attach to containers on that host. It is lost on me if/how a devcontainer.json comes into play here.)

[twodrops]

This issue is really imporant for us as well. We have a safety critical development environment where we baseline our tools and roll it our as Docker Image + devcontainer.json. Because of this bug, the extensions are automatically updated on the user side. This comment by @lawrencegripper describes our problem clearly.

	"settings": {
		"extensions.autoUpdate": "false",
		"extensions.autoCheckUpdates": false,

	},
	"extensions": [
		"[email protected]"
	]

The problem becomes more severe when the extensions have two parts, an extension and a python based backend for it (like a language server). The frontend part of the extension easily runs out of sync because of the auto-update feature. We do not want to let users install the backend manually with a notification, as it can, for example, cause a lot of pip issues/conflicts.

[ras-relativity]

Dealing with this with omnisharp/C# extension.

The team needs v1.23.16, but it installs the latest (currently v1.24.4) on container startup. To fix:

1. Go to the C# extension in extension tab
2. Click the dropdown next to Uninstall Button -> Install another version -> v1.23.16
3. Click the Reload Required button

We use a devcontainer.json to install the extension, would like to put this, but it has no effect:
"extensions": [ "[email protected]", ],

[jankap]

This is crucial, anything we can do?

[temparus]

We use a devcontainer.json to install the extension, would like to put this, but it has no effect:
"extensions": [ "[email protected]", ],

We had the same issue lately. We got it working in VSCode version 1.68.1 with the following config in devcontainer.json:

{
    "settings": {
        "extensions.autoUpdate": false,
        "extensions.autoCheckUpdates": false
    },
    "extensions": [
        "[email protected]"
    ]
}

[twodrops]

@temparus Are you really sure? It does not work for me with 1.68.1 either.

During the first startup, it installs the specifed extension, but then it autoupdates itself.
Btw, I am testing it from a devcontainer.json. Don't know if this is now only a bug within devcontainer.json.

[temparus]

@twodrops you're right. It only works properly on the first start of the devcontainer. So, when the container already exists when opening the project in the devcontainer, the auto-update kicks in.

As a workaround, you can add an initializeCommand in the devcontainer.json file to remove the existing container prior to the start of the devcontainer:

{
    "initializeCommand": "docker rm <devcontainer-name>"
}

This enforces that the container is rebuilt on startup. Building the actual container should not take long because the images and build layers are already in the cache.

[Nitschi]

This is critical for us because we need to work with a Python2.7 Codebase and both the Python and Pylance Extension dropped support.

Manually installing the older version is becoming a real pain...

[rafaelkallis]

We are facing a similar situation where our codebase uses dotnet 3.1 but the official C# extension (https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csharp) does not support 3.1 anymore in their latest relase, hence an older extension version has to be used. (1.25.0 -> 1.24.4)

[vlockhead]

I am facing the same issue here, it would be nice to be able to specify the extension version in the devcontainer.json the point of running vscode in a docker is to have a known environment

Having to reload re-install the extension manually each time is a pain