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 https://github.com/Microsoft/vscode/issues/21839#issuecomment-375047098, 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

[oisteinwind]

This is a feature my team would like to use - it would be very much appreciated.

[chkp-roic]

+1

[fyesoft]

+1

[Yinteger]

+1

[brandonmnewman]

+1

[ikbelkirasan]

+1

[llgcode]

Hi, Suggestion, I think most of people here don't need a complete marketplace. I think what we need first is a command that install an extension from a trusted url.

[naivefun]

Besides customized extensions, the private marketplace should be able to select subset of public extensions into it. That way we have a complete required extensions in one place. Of cos the public extensions are just a proxied uri.

[thalition]

Hello, I am trying to get my VSCode to only being able to download extensions we in my team see fit our developers have. I have tried with changing some code in .\VSCode\resources\app\product.json where I deleted the link in "serviceUrl": "". This made it possible to deny our developers to just download extensions and meanwhile use the "install from VSIX" option. I tried with changing it to links to our artifactory but it was not as simple as that, can anyone help wtih this? or will it first be able to be changed when this feature is implemented? :)

[hilleer]

@thalition weird to limit your developers to your needs and not theirs :) However, it doesn't sound related to the feature-request of this issue but as an entirely different scenario and feature.

[thalition]

@hiller Well its to start off with, the developers can come to us and tell us if they need other extensions, but its more so we can keep track of Who have what extension if something was to go wrong. We do this for all software :-) so its not to limit our developers just to know Who got what and why :-) And as I understand this its a feature to make it possible to host a private internal marketplace, which i what i need, but I could be wrong :-)

[feldoh]

I agree with @thalition I think it's sort of the same thing. At the moment VSCode is bound to the main gallery. But we are air-gapped and thus a proxy is insufficient. So I'd also like to be able to link to our artifactory using something like the proposed additional extension gallery. We've got it set up for e.g. Maven, NPM, chocolatey, *nix packages etc so that your sources list (i.e. internal gallery) is artifactory and this has a mirror of the external repos as well as allowing us to have our own custom apps. As it stands I need to make a ticket for every extension I want or every update. If we could re-point the gallery to a mirror then we could install all the extensions available on the gallery as well as any internal ones.

[renanmt]

This is a much needed feature for my team. Can't wait for dev updates in this thread.

[hevayo]

We also have a similar requirement where we maintain a public plugin and need a developer channel to publish development version for a wider audience to test. So appreciate if you can add this feature.

[ajmas]

This would be useful in our firm for the same reasons. Maybe a good starting place would to allow the market place URL to be overridable in the settings file?

The next step would be to document the REST API.

At this point either a community effort or a a company like JFrog (thinking of their Artifactory product) could provide support? — I have no vested interests in JFrog, just their solution is what we use in the firm I work for.

[ajmas]

If you want to say you need this, then please add a thumbs up on the description of this ticket, rather adding a comment with a +1.

Your vote in the description of the ticket adds more value. - Thanks

[rusnasonov]

It seems like Autoupdating Google Chrome Extension or Intellij Custom Plugin Repository

1. Add update_url to package.json. It's a link to update manifest
2. Add update manifest support. Update manifest contains extension version and link to source file (.vsix)

It's a very simple and flexible workflow. For example, you can host own extension on Github easily using Github Releases.

[gholt-aws]

+3 We need this for VS Code, Visual Studio and Azure DevOps.

[danielnmsft]

for me, the biggest advantage over vsix of being able to distribute via a private marketplace is auto-update functionality. This is something I'm working on adding to my extension itself to get around the current limitation, but it would be great to take advantage of the marketplace so private extension updates can be automatically applied without any extra work.

[acohen716]

Any update on this?

[hbjydev]

@acohen716 While MS could throw us a big wowie and make the marketplace open source, I doubt they will sadly. So... I doubt there's ever gonna be another official update for a long time.

[chrisdias]

hi - its unlikely that we would open source the marketplace, but we are investigating the ability to have "unlisted" extensions. An unlisted extension would be in the marketplace, have a URL, but wouldn't be searchable. Once installed (manually), it would then get automatically updated as normal.

[nirolevy]

Would love to see support for non-official extension repository

[orelkan]

@chrisdias, while this solution solves the use case of a company developing private extensions, it doesn't solve the problem for companies working in closed networks.

We would appreciate it if we could have our own repository in the network

[syncush]

VSCode market should be open source and be able to run in closed networks.

[mdfederici]

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.

I'll probably need to end up doing this as well it seems like. I have private IP in the plugin which I cannot put in a public marketplace even if the plugin isn't searchable and I need the plugin to auto update at a weekly release cadence. @levonmamikonyan do you still have this solution and do you have any code you are willing/able to let me look at?

[bhunsicker]

@levonmamikonyan I have the same need as @mdfederici . Are you willing to share some of that code you already have written? hate reinventing the wheel :)

[levonmamikonyan]

@mdfederici @bhunsicker I will be glad to share the solution (there isn't much to brag about :)). Just have to get an all clear before we can open source it. Will let you know how it goes.