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

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

sigurd.hansen_7559

I think its popular, not just because it's the default gallery for VSCodium, but also for a bunch of other VS Code forks (Cursor, VSCode-based IDEs and other forks) that can’t or won’t rely on Microsoft’s marketplace.

We also looking for an air-gapped lightweight offline marketplace.
Perhaps the reverse-engineering work OpenVSX has already done could be reused to expand ProGet's functionality?
Apidocs, Swagger, Github

-Sigurd

apxltd

Thanks @sigurd.hansen_7559 !

All right, I'm convinced.... this makes a lot more sense now to do now! I didn't quite realize that Microsoft does not allow non-VSCode clients to connect to their Marketplace, nor did I realize there were so many VSCode forks.

The current plan is to create a new feed type called "Open VSIX" or something that will support connectors. It should also be able to handle the "multi-file packages" (i.e. how the same extension can have multiple .vsix files but different architectures).

We should be able to just reverse engineer the VSIX API as well. That's clearly Open VSIX did; it's not all that complex I think. I've just now updated the other feed types; we don't have a date just yet, but it should e in the coming months. We'll keep this thread up to date.