[ProGet] Feature Request: Visual Studio Code - private Extension Gallery

dimas

I am currently looking into hosting my own internal vscode extensions gallery. Openvsx is pretty much the only viable candidate, but it requires spawning multiple docker containers with relatively large compute and ram requirements for my small 15 person team that probably only updates our airgapped vscode once a month.

There is actually a documentation on how to host a vsix feed for vscode on proget, but after a quick test it can't differentiate builds for different architectures.

For example, the python extension has different builds for different archs. Uploading them only results in a single entry on the proget vsix feed.

apxltd

Hi @dimas ,

It looks like VSCode still doesn't support private galleries. I know users have been requesting it for over eight years now.... so maybe it'll come soon! But until then, we can't implement it in ProGet.

I'm not sure what you mean about the python extension... but I do know that a visx file uses some kind of GUID to uniquely identify an extension. If the different "versions" of python visx use that same ID/Version, then I suppose it would get overwritten.

Alex

dimas

@apxltd The extension actually have several builds for different platforms. You can download them using these links.

However, the ProGet VSIX feed doesn't distinguish between these builds. The only way to solve this problem was to create a separate feed for each platforms.

apxltd

Hey @dimas ,

Ah, that makes sense. Looking at the manifest files, they have the same Identity@Id (which is what ProGet uses for the Package Name) but a different Identity@TargetPlatform (which must be new-ish):

<Identity Language="en-US" Id="python" Version="2025.2.0" Publisher="ms-python" TargetPlatform="win32-x64"/>
<Identity Language="en-US" Id="python" Version="2025.2.0" Publisher="ms-python" TargetPlatform="linux-x64"/>

We could probably figure something out in ProGet, but it's not trivial when it comes time to changing how we identify Package Names.

Can you try editing the manfiest file inside the vsix archive, and seeing if that works for your use case?

So basically:

<Identity Language="en-US" Id="python-win32-x64" Version="2025.2.0" Publisher="ms-python" TargetPlatform="win32-x64"/>
<Identity Language="en-US" Id="python-linux-x64" Version="2025.2.0" Publisher="ms-python" TargetPlatform="linux-x64"/>

Not quite sure if that would work, but figure it's worth a try.

Thanks,
Alex

sebastien.gamby_3349

Hello,

My organisation is also planning to host a private repository of VSCode extensions. Is there any chance that ProGet will implement this new feed type in the foreseeable future?

Kind regards,

Sebastien

apxltd

@sebastien-gamby_3349 check with the VSCode team.

They first need to implement support for private repository/galleries, and then we'd need to see some level of stability before considering it.

fbiryukov_8162

Does this recent announcement change anything for this feature request?

Introducing the Visual Studio Code Private Marketplace: Your Team's Secure, Curated Extension Hub .

apxltd

Hi @fbiryukov_8162,

I did a quick read of the content, and based on this statement ...

"Private Marketplace is available to GitHub Enterprise customers. VS Code users must sign in with a GitHub Enterprise or Copilot Business or Enterprise account to access." sounds to me like a closed ecosystem

And these technical instructions ...

https://github.com/microsoft/vsmarketplace/blob/main/privatemarketplace/latest/README.md#5-connect-vs-code-to-the-private-marketplace

... this is a locked-down / closed ecosystem. There's no published API/specs and no still no support in VSCode for private galleries. They're just "hacking" internal settings to get VSCode to use a different service URL, which they also control.

Obviously this is not something we could/would want to reverse engineer and then support.

If the VSCode team adds support for private repository/galleries (and a public/documented API), and there's some degree of stability to that, we'll consider it. But until then, not much we can do.

Best,
Alex

xabur

My company is also looking for a air-cap solution. It really is a pain and unfortunately, the Microsoft solution that requires GitHub Enterprise isn't a good fit. That's why we'd really like to have a solution like ProGet.

As I understand it, two things are required:

It must be possible to configure custom service endpoints in VS Code
--> Microsoft allows this with these settings: https://github.com/microsoft/vsmarketplace/blob/main/privatemarketplace/latest/README.md#5-connect-vs-code-to-the-private-marketplace
The API documentation must be available
--> There is no official documentation from Microsoft. However, Open VSX has documented the API for its VS Code adapter here: https://open-vsx.org/swagger-ui/index.html?urls.primaryName=VSCode Adapter# The question now is whether this documentation is reliable enough for you to adapt it. The API doesn’t actually look very comprehensive. It would be great if you could look into that

Another approach would be a VS Code "Private Marketplace" extension that supports NPM registries. There are some available, but they don’t seem to be actively maintained and are therefore not very trustworthy.

apxltd

Hi @xabur ,

Thanks for sharing the additional information! I've been meaning to research this more in depth, but just ran out of time.

I can't quite seem to figure out what Open VSX is exactly. So far as I can tell, it's like an alternative the Visual Studio Gallery. Meaning, you plug in https://open-vsx.org/ in VS Code, and then all the requests go through their service instead of the official gallery?

If that's the case, what's the use case? They appear to have all the same extensions, so this just feels like one of those "GooglePlay store alternatives" on Android... except there's no account/registration/etc required with the Visual Studio Gallery. Right?

Open VSX clearly seems to be popular, I just don't understand why.

In any case, if a well-supported project "reverse engineered" the official gallery and then made an alternative, that kinda paves the path for us. We don't want to be the first or only game in town, when it comes to supporting feed types.

Thanks,
Alex