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

sebastian.lieschke_5424

Hello inedo-Team,

as we're using heavily ProGet for development we also use heavily VS Codium.
Therefore we would like to be able to use our own private Extension Gallery to make use of the wonderful possibilites given by extensions. Also we want to be able to use our own-developed Extensions more intense across our teams.
At the moment we have to make it "the manual way" for internal usage of extensions: download vsix, upload to an internal vsix-feed on proget and then the developers have to download it from there again and install it manually.
It would be absolutely awesome to be able to use proget as an internal gallery for our vs code using developers but we couldn't figure out how.
We would like to set our own gallery as described here: https://github.com/VSCodium/vscodium/blob/master/docs/index.md#how-to-use-a-different-extension-gallery
Unfortunately proget-vsix-feeds seem to not provide the required endpoints (or we didn't find out how :) )
Could you please add that feature or provide a guide how to set up?

Thanks!
Sebastian

apxltd

Hi @sebastian-lieschke_5424 ,

Thanks for the request; this is something that is close to requesting a new feed type, so I'll use that rubric to decide.

As we wrote in that link, new feeds can be very time-consuming to research, develop, document, maintain, etc. Like with all software, even estimating the cost is costly - so we can't really even begin the initial research until there's sufficient demand or market opportunity to justify the possible investment.

To be honest, I don't see there being much demand or any market opportunity for this. Time will tell, and maybe someone will comment on this in the future. But for now this seems really niche.

That being said - I took a quick look at the document you linked, and I don't see API docs (i.e. those missing endpoints you mentioned). Maybe it's something as simple as a basic JSON document. Maybe it's an absurdly complex and undocumented API.

However, if you can figure how the API works, and it turns out to be something like a simple JSON/XML index file.... and you can prototype/fake that using a static file inside of a ProGet Asset Directory... then we can likely implement that quite easily.

I know that's how RPM and Helm Chart feeds got started long ago :)

Alex

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