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" <[email protected]> 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

[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)

[seaniyer]

Hi all,

Please take this Private Marketplace Survey

VS Marketplace team is conducting a quick survey to gather the latest customer input on Private Marketplace asks. We are scoping and planning a solution, so your response will be timely in helping shape any Private Marketplace offering from Microsoft. 

Thank you on behalf of VS Marketplace team!
cc: @isidorn @svermamsft

[deadmeu]

Hi all,

Please take this Private Marketplace Survey

VS Marketplace team is conducting a quick survey to gather the latest customer input on Private Marketplace asks. We are scoping and planning a solution, so your response will be timely in helping shape any Private Marketplace offering from Microsoft.

Thank you on behalf of VS Marketplace team! cc: @isidorn

Hi, before I open your URL, I can see that you are not a "member" of this project. How can we verify you?

[seaniyer]

Hi, before I open your URL, I can see that you are not a "member" of this project. How can we verify you?

Sorry to hear that. This may be a localized issue as few others were already able to take the survey. @deadmeu, one suggestion is to try the link from an InPrivate browser window.

[omerd-cyera]

I fully agree with @deadmeu, I'm also not seeing a "member" tag. Also, opening in a private browser window isn't really reassuring

[deadmeu]

Hi, before I open your URL, I can see that you are not a "member" of this project. How can we verify you?

Sorry to hear that. This may be a localized issue as few others were already able to take the survey. @deadmeu, one suggestion is to try the link from an InPrivate browser window.

Sorry, there may have been a misunderstanding here. I have not yet even tried to access the survey.

All I'm suggesting is that there are often fake profiles commenting in GitHub repos (especially these days). It would be a good practice to make sure you are communicating from a trusted GitHub account, that is clearly identified and verified, especially when you are asking people to navigate offsite to a non-Microsoft domain.

E.g. I don't see you listed here https://github.com/orgs/microsoft/people?query=seaniyer

[isidorn]

@seaniyer works on our VS Marketplace. I am a PM working on VS Code.
You can trust the link he posted.

[jvilk-stripe]

I filled out the survey. Feel free to reach out if you want to chat more about our use cases at Stripe.

[isidorn]

Thank you very much for your replies in the survey.
In the survey, I noticed that some of you would like an allow list of extensions from the public marketplace. Please be aware that we are launching this feature next week in VS Code Insiders. And more details can be found here #84756

Feedback is very much welcome!

[kineticsquid]

We think the idea of a private marketplace is a great idea. In fact, we have one of these at the Eclipse Foundation Open VSX Registry at open-vsx.org. It's an open, transparent, vendor neutral registry for VS Code extensions comprised of three Eclipse open source projects and governed by the Eclipse Open VSX Working Group.

• https://github.com/EclipseFdn/open-vsx.org
• https://github.com/eclipse/openvsx
• https://github.com/open-vsx/publish-extensions

Easily deployable in house in a tethered or untethered configuration, including in an air-gapped environment. You can try it out quickly locally or with a couple of clicks at Gitpod. We also have a PR coming through to provide the same for Red Hat OpenShift.