Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Does .net not have a way to run simple private repository like Nexus? Over in JVM-land that's a basic thing that you'd be doing anyway.


It's the difference between drag-dropping a reference between "projects" or whatnot in your monolith project, or coming up with a publish pipeline after which your merged code gets into the repo so that other people can use it, if you have three projects in three checkouts that all have to be coordinated and merged in order so that you don't accidentally break your environment and worry about security and and and....

One is much simpler than the other. Artifact management is surprisingly complex, it only looks like it works great while you aren't managing many versions and acting more like a monolith, just spread across repos/deploy points.


> It's the difference between drag-dropping a reference between "projects" or whatnot in your monolith project, or coming up with a publish pipeline after which your merged code gets into the repo so that other people can use it

You already have that pipeline for release/deployment though, don't you? (And it's already hooked up to your SSO or what have you).

> if you have three projects in three checkouts that all have to be coordinated and merged in order so that you don't accidentally break your environment and worry about security and and and....

It's the same as any other library dependency though, which is a completely normal thing to deal with. The cost of separating your pieces enough that you can use different versions of a library in different services is that you can use different versions of a library in different services.

I'm skeptical about microservices as a deployment model, but I'm absolutely convinced that code-level modularisation and independent release cycles for things that deploy independently are worthwhile, at least if your language ecosystem has decent dependency management.


The only way package feed complexity works -- and really microservices in general -- is to be absolutely fastidious about backwards compatibility of your packages and as open as possible with transitive dependency versions.

Nuget does provide mechanisms for obsoleting packages, so it's reasonable to enforce that new packages should allow for a few versions worth of backwards compatibility before deprecation and finally pulling the plug.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: