this post was submitted on 03 Aug 2023
2 points (100.0% liked)

.NET

1474 readers
1 users here now

Getting started

Useful resources

IDEs and code editors

Tools

Rules

Related communities

Wikipedia pages

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
2
Private Nuget feed hosting (programming.dev)
submitted 1 year ago by [email protected] to c/[email protected]
12 comments fedilink hide all child comments
 

I wanted to exchange some experience regarding private NuGet feed hosting solutions.

We have used MyGet for years both for our private and public packages. But recently it became so unstable that it would not be responsible to not investigate the alternatives. I looked into Azure Artifacts first because, we already have Azure Devops and it comes free. The transition was mostly painless (I plan to write about it in more detail soon). But hosting public feeds doesn't seem as easy. One needs to create a public project just for that. So, we still use MyGet for public feeds for now. But will move them also elsewhere.

What are your experiences with private feed hosting? Do you host them yourselves or use a paid service?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 4 points 1 year ago* (last edited 1 year ago) (6 children)

Azure Artifacts has been great for private stuff. Have you tried Github packages yet? Works well enough for public packages. I don't know what your use case is, but what prevents you from using nuget.org?

[–] [email protected] 3 points 1 year ago (4 children)

Have you tried Github packages yet?

No. Thank you for the suggestion. We use Azure Devops, but I would expect it to have good integration with GitHub. But creating a public project in Azure Devops may make more sense (so that all packages are in one place).

[...] but what prevents you to use nuget.org?

The only thing is possible name collisions. I didn't start looking into this, but it is a possibility. Otherwise I think we will end up doing this.

[–] [email protected] 2 points 1 year ago (1 children)

Aah yes, naming collisions. I hadn't considered that. I'm curious what kind packages you want to make available to the public are also prone to naming collisions that can be solved by a namespace convention. Are you publishing libraries, applications, VS extensions or templates?

[–] [email protected] 2 points 1 year ago

We are publishing libraries (mostly client libraries). There are lots of legacy stuff. It's safer to own the whole feed instead of pushing it to nuget.org and hoping for the best :)

load more comments (2 replies)
load more comments (3 replies)