Feature Request: Support for private marketplace/gallery

[levonmamikonyan]

We have created several VSIX extension that have no use to anybody else except our company. We would like to host our own private extension gallery and have an ability to specify alternative extension gallery paths (like "Additional Extension Galleries" in Visual Studio 2015).

• VSCode Version: 1.10.1
• OS Version: Windows 10

[seanmcbreen]

Hi,

Currently we don't have a way to do this but it's not the first time we have heard this request so adding the correct label. We don't have this in our current backlog but this will help us keep track of it.

Thanks
Sean

[hilleer]

This is a feature that we would welcome very, very much as well, as it's kind of time consuming and annoying to have to build and forward the vsix file every time you make changes :-)

[hilleer]

Anyone got updates on this?

[ibigpapa]

So viewing the code don't think i'll have time anytime soon to submit pull request.

https://github.com/Microsoft/vscode/blob/67cd9258fd0ed429ddc626d488d48bd65c2f2283/build/lib/extensions.js#L48

https://github.com/Microsoft/vscode/blob/67cd9258fd0ed429ddc626d488d48bd65c2f2283/build/lib/extensions.js#L67

https://github.com/Microsoft/vscode/blob/67cd9258fd0ed429ddc626d488d48bd65c2f2283/build/lib/extensions.js#L75

These appear to be the main lines used for getting extensions from the market place. I guess you could replace the url with a call to the config to pull the URL and insert a local cached proxy so it would pull from the local proxy if package is there if not pull from marketplace. Then just provide the functions for the query and the upload that mimic the calls from vscode.

Cons to this would be https issues.

Ideally you would modify the Extensions: Market Place UI to provide a filter to a custom repository and market place filter. Something like Show Marketplace Only, Show {Custom name} Only, Show All.

Then modify the original code to query both places and merge the content. You'll probably want to add an indicator that would show what repository it is from. Maybe a dot with a color that indicates this. Something like blue for Marketplace and red for non market place with a tooltip that would spell out the repository name when moused over.

[Luraktinus]

any news there?

[hilleer]

@Luraktinus I haven't read any news regarding this, unfortunately.

[llgcode]

Also interested in having this feature.

[Luraktinus]

yeah, understandable

[gvanbeck]

+1

[bjoernbusch]

This would be really nice.

[notlaforge]

Is it possible to publish extensions on the marketplace and have them not appear in search?

I'm thinking for cases where the extension is not really secret, just not generally useful outside a company.

[sijakret]

+1
i believe this is an important feature for all sorts of custom toolings

[Luraktinus]

i am fine with the ability to just copy/paste the addon in the extension folder....
the community could develop an own gallery already

[hilleer]

@Luraktinus so if you have a private extension that many employees are using, flow could be as following;

1. Distribute it to employees.
2. Employees all have to install it manually.

This, to me at least, includes a lot of time wasted, compared to just distributing it to something like the marketplace.

[Luraktinus]

@hilleer

I mean that the community could do a plug-in to replace the functionality of the gallery.

[levonmamikonyan]

As a stop gap we've setup an in-house webserver and hosted all extensions there.
It also exposed an API endpoint to return latest number version for a given extension.
Then for every extension we had a timer to ping service every minute, check the version and compare with the one installed.
So if a new version was detected it would prompt to upgrade and then from the it was just a bunch of chained promises (show a prompt, on OK download an extension, show a prompt to restart, restart).
Then the last step was to automate a build pipeline, so every extension release was properly deployed to webserver (really package the extension and copy to appropriate folder).
The only drawback is that the extensions must be installed manually for the first time, from there on it's all automated.

[jan-dolejsi]

Yeah. I have implement one of those custom plugin galleries before for another extensible product I worked on. The plugins were managed in a SharePoint document library. It dealt with the versioning, exposed a RESTful interface, authentication, possibly user authorization. It worked. But more and more enterprises move to O365. where it is suddenly much more difficult for a desktop application to interact with. So if you tried to implement this custom extension gallery based on any cloud hosted repository with 2 factor authentication, you would have to take the user through the authentication, store the access token and refresh again when it expires... The bottom line is that the biggest challenge is not to get the extension to the right users, but to keep the extension up to date with subsequent updates. What does not help is that the .vsix file does not _just install_ when you double click on it, but rather says it is invalid for any of the _Visual Studio_ installation you have. I realize I am not bringing any constructive suggestions here. Sorry. Jan On Mar 21, 2018 19:22, "levonmamikonyan" <notifications@github.com> wrote: As a stop gap we've setup an in-house webserver and hosted all extensions there. It also exposed an API endpoint to return latest number version for a given extension. Then for every extension we had a timer to ping service every minute, check the version and compare with the one installed. So if a new version was detected it would prompt to upgrade and then from the it was just a bunch of chained promises (show a prompt, on OK download an extension, show a prompt to restart, restart). Then the last step was to automate a build pipeline, so every extension release was properly deployed to webserver (really package the extension and copy to appropriate folder). The only drawback is that the extensions must be installed manually for the first time, from there on it's all automated. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#21839 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AXScHf08PALlGkvbqbrfuRGVbvEM_dg4ks5tgppcgaJpZM4MRofM> .

[darkvertex]

Also interested in this. Would be super nice to have.

[itzik-h]

@seanmcbreen would you consider external help for that one?

[roysudi]

+1

[jkasun]

+1

[Ubeek]

+1

[GitMensch]

VS Code does not allow anyone to extend marketplace client (ie. extension view) in VS Code

... which would not necessary if one could override the target endpoints - see #129764 from 2021 for a working solution (which you can use if you build vscode from scratch); or if vscode would allow to specifiy multiple/additional endpoints.

and not to mention marketplace APIs are hot mess to clone.

... there are several projects mentioned here that exactly do this, including osvx-registry (the software, not the public instance run by Eclipse).

For someone who isn’t actively working on the project, can anyone who knows indicate whether the issue is technical or policy?

That's more @isidorn to answer but @sandy081 closed the mentioned PR and similar issues because "the marketplace team has come up with a plan" two years ago, which they seem to have dropped. Maybe it is time to re-review the PR (if it is reopened I'd update it, of course)?

[jeanp413]

@timheuer @prashantvc is/will https://github.com/prashantvc/extensions officially mantained by microsoft or it's just another free alternative like the ones already mentioned in this issue?

[prashantvc]

@jeanp413 it’s one of my side projects that I am working. The project is not connected to Microsoft in anyway

[msweeney1999]

I too need this feature.

[Dongyang0810]

+1

[maxenium]

I strongly support the idea of implementing a private extensions store for Visual Studio Code. As a representative of many companies and organizations, we often find ourselves in a situation where we need to develop and use in-house extensions and tools, but sharing them on the public marketplace is simply not an option due to sensitive data and intellectual property concerns.

The current landscape has led to workarounds such as relying on third-party plugins or tools to create private extensions stores e.g. Private Extension Manager. However, these solutions often come with their own set of problems. Many of these third-party plugins are no longer actively maintained, and they tend to break with newer versions of VS Code and its dependencies. This makes managing private extensions within a corporate environment impossible without going the manual route of downloading vsix files.

One significant issue we've encountered is the configuration of proxy settings. Outdated extensions fail to recognize and adapt to the latest proxy configurations, which can lead to connectivity issues and security vulnerabilities. For instance, newer versions of VS Code do not work with the "Private Extensions Manager" and the 'no_proxy' settings are not being recognized, causing problems when working behind a proxy.

A dedicated private extensions store within VS Code would address these issues and provide a secure and reliable way for companies to make their proprietary extensions available to their employees. It would enhance the development workflow, streamline the distribution of internal tools, and ultimately improve productivity and collaboration within the organization.

I believe this feature would be a valuable addition to Visual Studio Code, benefiting both individual developers and enterprises alike.

I am wondering why this feature request gets so little attention from the development team. 😢

[Zane-XY]

Need this feature! Super important for enterprise users. May just reference what IntelliJ platform does.

[taturou]

I would appreciate this feature.
I am creating private tools, and distributing updates is very tedious.

[omerd-cyera]

+1

[gjsjohnmurray]

Se also #179919

[zentby]

Try integrate this Auto Updater plugin into your extension.

With this extension, your extension can be hosted in your private website(e.g. behind a VPN).

[seaniyer]

FYI @JacquelineWiddis

[GitMensch]

Need this af

posting here obviously don't help... either you build vscode yourself, applying the related PR to run a private instance for example of openvsx (that PR was closed because "the marketplace team has come up with a plan" nearly 3 years ago - we all see how well and timely that worked out...), or use vscodium, which did accept a similar patch, or use something like https://marketplace.visualstudio.com/items?itemName=zokugun.vsix-manager which allows to install extensions from any workplace or locally (but needs manual setup of the extensions).

[omerd-cyera]

I ended up creating releases in github that have the vsix file, and created a component inside the extension that checks for updates periodically, and updates itself.

Not perfect, but its simpler than you think to implement, and it doesn't require extension consumers anything apart for installing the extension from vsix once.

[fone-almosca]

@omerd-cyera That's exactly what i'm trying to do for the past 2 days, but when I arrive to the point of uploading the .vsix file into release asset, i get the error:

"Resource not accessible by integration"

I'm pretty sure the token has the correct rights, as the upload works for every file except .vsix.
So I'm wondering, if you had the same issue, how did you solve it ?

[omerd-cyera]

@fone-almosca I think vsix is not supported in gh. Just zip or tar it.

[gaby]

7 years later and this issue still open? @isidorn Any updates on this?

[haudan]

@omerd-cyera

I ended up creating releases in github that have the vsix file, and created a component inside the extension that checks for updates periodically, and updates itself.

How did you accomplish the automatic updating? Do you just invoke the workbench.extensions.action.installVSIX command?

[omerd-cyera]

I have other tools installed on all relevant machines that are responsible for first install and updates. In my case it was easier to just trigger them via the cli.
I think that in most cases workbench.extensions.action.installVSIX is the way to go.

[harbingerofcode]

In light of the following article, wouldn't you say that the need for this feature becomes more pressing?

https://www.bleepingcomputer.com/news/security/malicious-vscode-extensions-with-millions-of-installs-discovered/amp/

"Microsoft's lack of stringent controls and code reviewing mechanisms on the VSCode Marketplace allows threat actors to perform rampant abuse of the platform, with it getting worse as the platform is increasingly used."

I work for an org that hosts private NPM, NUGET and Visual Studio extension gallery where we curate the packages we host. It feels like a natural progression to allow this for VS code, especially with with integration through ADO Artefacts.

[GitMensch]

As already noted: you can use and curate your own extension marketplace by setting up a "local" entry point target, for example an OpenVSX instance and adjusting package.json to point to that.
In a corporate environment I guess you use a central installation of vscode so that's no big issue, You may drop the marketplace entry points completely as well.

For "local" or "project" scope you can add the curation to the .vscode folder since recently (which together with disabling the other entry points or moving them to a controlled instance).

[harbingerofcode]

#84756 (comment)

[swythan]

As already noted: you can use and curate your own extension marketplace by setting up a "local" entry point target, for example an OpenVSX instance and adjusting package.json to point to that.

I guess this was in response to the preceding comment. Just to be clear though, this wouldn't solve the problem in the OP (which I share): to have an internal marketplace in addition to the main public marketplace.

[danielboucek]

For those of you who use Gitlab. I recently created an extension that uses Gitlab's Package Registry API. Allowing you to browse, install, and auto-update private extensions.
You can check it out if you like. It works surprisingly well.
Private Extension Manager - GitLab

[macserv]

As already noted: you can use and curate your own extension marketplace by … adjusting package.json to point to that.

This is problematic on macOS, as the package.json file resides inside the signed app bundle, and modifying it invalidates the application's signature. This causes the system to present the user with additional verification requests before the "damaged" application can be opened.

More seriously, starting in macOS 15.0 Sequoia, this verification step requires the user to be an Administrator, which isn't commonly the case in a corporate environment.

This is easier to work around with VSCodium, which includes a patch for observing the contents of a product.json file in the user-data path as well as the one inside the app bundle.

[GitMensch]

Well said @macserv and not to forget - that also includes the option to override endpoints using environment variables, so you don't even need a file... and of course, that patch from VSCodium is quite similar to the one suggested upstream which was denied in 2021 as a "temporary workaround" because "the market team discusses that". As that's more than 3 years ago friendly ping @sandy081 is there a solution "in sight" and you can give details about this? If not: please reconsider applying this patch temporarily for the next 2-5 years (could have been 5+, you know).

[sameemqureshi]

We are setting up our private Extension on JFrog Artifactory , For the First time the Users would be getting the Extension from the Artifactory itslef.
there are going to be updates for this extension , we want to implement a seamless update flow for the users , where there extension would be pinging too check for any updates and If found , notify and update the extension,
How can this Update flow be seamless , where user just needs o click the update , and latest version is taken?
how can it be automated??

#21839 (comment)