You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In your extension activation callback, you are free to check and download extensions as soon as the extension get's activated. This is how Live Share is downloading their dependencies after installation
export async function activate(context: vscode.ExtensionContext) {
/// 1 Check if deps are installed
await downloadDependencies()
// Update status bar or output channel to give an indicator of status
}
An extension can install necessary libraries and stuff using this post install script. An unique location per extension is provided through an env variable for the extension to maintain any state. The same location will also be passed with post uninstall script.
Reacted by Nico Lueg, Mickey Pearce, Wout Mertens and Jean-Baptiste Lièvremont
Idea is to provide a post install hook similar to uninstall hook. This will be executed after an extension is installed or updated.
I would prefer a better name. Today vscode:prepublish applies to developer of the extension, i.e. to extension authors. Having vscode: install would indicate it's related to extension authors again and not in end user machines.
Sandeep Somavarapu (@sandy081) Thanks for pointing this feature out to us on the C# extension. Our dependency downloading story is actually a little complicated. Each version of the extension ships with built in URLs to specific versions of binary dependencies, and, if the user has no options set, we'll download them on first run. However, we allow users to control what version of our dependencies they download. You can see this in action by playing with the option "omnisharp.path". If you:
Set it to latest: When the extension starts, it will check online to determine the latest version of OmniSharp, download it if we haven't downloaded it before, and start that version. Each new version gets downloaded to its own folder.
Set it to a specific version number: When starting OmniSharp, the extension will attempt to start it from a directory based on the version you specified. If it's not available, it will try to download it using a well known version -> url mapping.
Basically, we need to be able to access our "unique location per extension" after install-time to read and write values. Would the new API support that?
Sandeep Somavarapu (@sandy081) In addition to what Ravi said, I would first off like to say a thanks. I have been wanting this feature for so long. So I am very excited to see it happening!
Two other notes --
I am not sure what kind of UI interactions you are expecting to allow between the post install script and VS Code, but we would need to somehow inform the user of progress since downloads can be somewhat large, at least for users with very slow internet connections.
I would expect the most common action that an extension to want to do would be to install dependencies. However, with proxy servers, downloading files is not that easy of a task to get right. It would be great if there was some sort of 'DownloadFile' API or 'vscode-DownloadFile' npm package that was provided to extensions that would handle this task in the same way that VS Code does. In case it matters, as Ravi said, I think we would want some of our downloads to continue to go to the per-extension-version directory (because they change with essentially every version), while some of our downloads are stable enough that we might want to share them. So we would need to be able to specify the destination directory in such a way that either place could be targeted.
Here is the C# extension "download dependencies" code as a reference:
I would also think it would be a good idea to offer up a "generic" platform that's a fallback if you haven't published the right one. I don't think it's good for extensions to have to keep track of every platform VS Code could support (present and future) and ensure they publish versions for each of them. There's always the case that a new platform (say, darwin arm64) appears, then some older extension can no longer be used because it won't be installed unless you have the platform available.
But, I know this (and the insiders versioning) is sort of limited by what the marketplace can do.
Reacted by Brett Cannon, Fred Bricon, Ilia Pozdnyakov, Felipe Santos, actboy168, Jonas Bushart and Jinbo Wang
Jake Bailey (@jakebailey) this is a good suggestion, however we are a bit limited due to marketplace support.
We should keep this in mind and potentially improve later, but this is not in the cards for the near future.
Current limit per platform package is 200mb. This is not set in stone, we can increase if we hear from you it is needed.
Thanks. For the C# extension, have one platform (darwin-arm64) where we are fairly close to the limit -- 198425276 bytes (189.2 MB) in my quick test. I can do some experiments to see if we can reduce this a bit. But we have have an ask to raise this slightly.
Gregg Miskelly (@gregg-miskelly) ok, so it seems like we are good for now but I have notified the Marketplace that we would like to increase the size limit. Once they do that I will let you know.
Reacted by Prashant Cholachagudda and Julian Valentin
Thus I am closing this issue. If there are questions feel free to ask, we will continue monitoring this issue even though it is closed. Thank you very much 👏
Reacted by Prashant Cholachagudda, Christof Marti, Sandeep Somavarapu and João Moreno
Just a question, because I didn't understand, was the thing about having to release different versions for non-platform specific and platform specific extensions solved?
I.e. can I release a amd64 and a non-platform specific .vsix targetting the same version?
Felipe Santos (@felipecrs) yes you can, but you need to publish your amd64 vsix for amd64, and your general one for each other platform. This is an issue to help make this flow smoother microsoft/vscode-vsce#625
Isidor Nikolic (@isidorn) When Marketplace increases the size limit, is this announced in this issue or in another? Or is this documented somewhere? I can't find the info about the 200MB anywhere else than here (the previous limit of 100MB is also hard to find, it's buried in some old release notes of VS Code).
Whether it's 200MB or say 250MB or 300MB makes a big difference for my extension with respect to migrating to platform-specific extensions, but I don't know a way of finding out the current limit other than trying to publish and see what happens. Obviously, at that point, a lot of effort has been invested, in vain if the limit is lower than expected.
Julian Valentin (@valentjn) The size limit is not documented anywhere. Right now, we have 200MB limit, however we allow larger extension on need bases.
PS: I opened an issue to VS Marketplace to support generic platform, so that extension authors would not need to manage their own list of all platforms.
Activity
[-]Any hooks can be executed after VSIX package installed?[/-][+]Extension post-install hooks[/+]auchenberg commentedon Jul 18, 2018
In your extension activation callback, you are free to check and download extensions as soon as the extension get's activated. This is how Live Share is downloading their dependencies after installation
windyGex commentedon Jul 19, 2018
If install dependencies when extension activate, I think it' too later and it maybe cost a long time.
sandy081 commentedon Nov 20, 2018
Idea is to provide a post install hook similar to uninstall hook. This will be executed after an extension is installed or updated.
An extension can install necessary libraries and stuff using this post install script. An unique location per extension is provided through an env variable for the extension to maintain any state. The same location will also be passed with post uninstall script.
DonJayamanne commentedon Nov 20, 2018
I would prefer a better name. Today
vscode:prepublishapplies to developer of the extension, i.e. to extension authors. Havingvscode: installwould indicate it's related to extension authors again and not in end user machines.rchande commentedon Nov 20, 2018
Sandeep Somavarapu (@sandy081) Thanks for pointing this feature out to us on the C# extension. Our dependency downloading story is actually a little complicated. Each version of the extension ships with built in URLs to specific versions of binary dependencies, and, if the user has no options set, we'll download them on first run. However, we allow users to control what version of our dependencies they download. You can see this in action by playing with the option "omnisharp.path". If you:
latest: When the extension starts, it will check online to determine the latest version of OmniSharp, download it if we haven't downloaded it before, and start that version. Each new version gets downloaded to its own folder.Basically, we need to be able to access our "unique location per extension" after install-time to read and write values. Would the new API support that?
gregg-miskelly commentedon Nov 21, 2018
Sandeep Somavarapu (@sandy081) In addition to what Ravi said, I would first off like to say a thanks. I have been wanting this feature for so long. So I am very excited to see it happening!
Two other notes --
Here is the C# extension "download dependencies" code as a reference:
89 remaining items
jakebailey commentedon Sep 16, 2021
I would also think it would be a good idea to offer up a "generic" platform that's a fallback if you haven't published the right one. I don't think it's good for extensions to have to keep track of every platform VS Code could support (present and future) and ensure they publish versions for each of them. There's always the case that a new platform (say, darwin arm64) appears, then some older extension can no longer be used because it won't be installed unless you have the platform available.
But, I know this (and the insiders versioning) is sort of limited by what the marketplace can do.
isidorn commentedon Sep 16, 2021
Jake Bailey (@jakebailey) this is a good suggestion, however we are a bit limited due to marketplace support.
We should keep this in mind and potentially improve later, but this is not in the cards for the near future.
gregg-miskelly commentedon Sep 16, 2021
Thanks. For the C# extension, have one platform (darwin-arm64) where we are fairly close to the limit -- 198425276 bytes (189.2 MB) in my quick test. I can do some experiments to see if we can reduce this a bit. But we have have an ask to raise this slightly.
isidorn commentedon Sep 17, 2021
Gregg Miskelly (@gregg-miskelly) ok, so it seems like we are good for now but I have notified the Marketplace that we would like to increase the size limit. Once they do that I will let you know.
isidorn commentedon Sep 24, 2021
As I mentioned above
We now support the full flow for platform specific extensions 🚀
This document has all the details:
https://code.visualstudio.com/api/working-with-extensions/publishing-extension#platformspecific-extensions
Thus I am closing this issue. If there are questions feel free to ask, we will continue monitoring this issue even though it is closed. Thank you very much 👏
felipecrs commentedon Oct 12, 2021
Just a question, because I didn't understand, was the thing about having to release different versions for non-platform specific and platform specific extensions solved?
I.e. can I release a
amd64and a non-platform specific.vsixtargetting the same version?isidorn commentedon Oct 12, 2021
Felipe Santos (@felipecrs) yes you can, but you need to publish your
amd64vsix foramd64, and your general one for each other platform. This is an issue to help make this flow smoother microsoft/vscode-vsce#625felipecrs commentedon Oct 12, 2021
Isidor Nikolic (@isidorn) thank you!
valentjn commentedon Oct 14, 2021
Isidor Nikolic (@isidorn) When Marketplace increases the size limit, is this announced in this issue or in another? Or is this documented somewhere? I can't find the info about the 200MB anywhere else than here (the previous limit of 100MB is also hard to find, it's buried in some old release notes of VS Code).
Whether it's 200MB or say 250MB or 300MB makes a big difference for my extension with respect to migrating to platform-specific extensions, but I don't know a way of finding out the current limit other than trying to publish and see what happens. Obviously, at that point, a lot of effort has been invested, in vain if the limit is lower than expected.
prashantvc commentedon Oct 14, 2021
Julian Valentin (@valentjn) The size limit is not documented anywhere. Right now, we have 200MB limit, however we allow larger extension on need bases.
felipecrs commentedon Oct 22, 2021
PS: I opened an issue to VS Marketplace to support
genericplatform, so that extension authors would not need to manage their own list of all platforms.microsoft/vsmarketplace#219