Extension is not deactivated during an extension upgrade

[joaomoreno]

We need to support extension deactivation. Primary use cases will be uninstallation and update.

Users are already hitting issues due to it:

So I and another user had an issue while trying to update an already-installed extension. If you go into “Install Extensions” and select the new version of the PowerShell extension, it tries to install but fails halfway through. If you reopen code, the plugin host starts crashing. You end up having to delete the extension folder manually before you can install the update.

I think this may be due to the fact that I’m running my language server process from inside of the extension folder. If the process is running, it seems to block the successful reinstall of the extension. Seems like we may need some way to kill the running extension before attempting to update it.

@daviwil

[egamma]

see also microsoft/vscode-go#26

[gep13]

@joaomoreno do we need a separate issue to track this requirement:

https://twitter.com/jchannon/status/667283133318889472

i.e. to get a notification about available updates for extensions?

[daviwil]

There is one:

#268

[gep13]

@daviwil said...
There is one:

Ah, perfect 👍

[alexdima]

With 98473e0, VSCode's extension host will now call deactivate() if extensions export it and call dispose() on ExtensionContext.subscriptions on shutdown, then will wait 1s before exiting

[daviwil]

The PowerShell extension has added a deactivate() method but I don't see it getting called when attempting to upgrade my extension in 0.10.4. With [email protected] installed, I attempted to upgrade to [email protected] and didn't see my language server get a shutdown request (which should be caused by the deactivate method).

Here's my main.ts file's deactivate method:

https://github.com/PowerShell/vscode-powershell/blob/master/src/main.ts#L106

Did I implement this incorrectly? Should I instead create a disposable that calls the necessary shutdown method?

Thanks!

[daviwil]

cc @dbaeumer since I'm using vscode-languageclient

[egamma]

adding @alexandrudima

[egamma]

@daviwil your implementation looks fine

I don't see it getting called when attempting to upgrade my extension in 0.10.4

Currently deactivate is only called when VS Code exits, it isn't called when you upgrade/reload.
Can you verify that deactivate is called when you shutdown Code.

[daviwil]

Yep, it definitely gets called during shutdown and also when I open a different workspace path. For me, the extension upgrade scenario was the biggest problem that deactivate would solve because the upgrade doesn't succeed while my language server process is still running (it's in the extension folder). Can this method be called at extension upgrade time too?

To clarify, my extension should be deactivated before the extension upgrade process starts.

[egamma]

Issue #567 tracks the deactivate on shutdown scenario.
Reopening this issue to track deactivate during an extension upgrade.

[egamma]

@daviwil the December update improved the way an extension is updated. The update is now installed into a new folder with the version suffix.

Can you please verify whether this support addresse the issues with PowerShell/vscode-powershell#27.

[daviwil]

Yep, I noticed the new folder layout, that is an improvement! One question about the new behavior - after you download and unpack the extension into the new version-specific folder, do you attempt to delete the older verson's extension folder? If so, does it happen before or after VS Code restarts? The only way we would still have a problem is if VS Code attempts to delete the old extension folder before it restarts because my language server process would still be running at this point.

[joaomoreno]

@daviwil Deletion will only happen after VS Code restarts.

[daviwil]

Perfect! I'll be releasing a new update to my extension in the next week or two, so I'll let you know if I see any issues when attempting an upgrade at that time. Feel free to close this issue for now, I'm pretty confident that your changes will have fixed it.