> "Just download this and everything will work "

Ah, the old debate in .Net between the lumpers and the splitters.

Between the "just install .Net and that's it, it makes no sense to install all these little interdependent pieces one at a time. it's too complex and versioning is hell" and the "this web server doesn't need the WPF libraries, it's just dead weight, bloat, and makes it harder to start up new machines. It makes no sense to bring out a new version of WPF because there's a bug fix in ASP. Or worse, delay release."

The thing is, there is no one right answer, only opposing forces that have to be reconciled.

.Net core started out fairly radical, which favoured the early adopters and neophiles who tend towards splitters, but is now generally veering towards larger corporate adoption, which tends to wards lumpers. But there are exceptions.

I don't think anyone really is angered by a modular system, its more the needing-to-pay-attention-to-every-little-bit (especially when those bits are mixed up in really poor naming, corporate speak, etc) is the more practical issue

> Between the "just install .Net and that's it [...]" and the "this web server doesn't need the WPF libraries, it's just dead weight [...]"

> The thing is, there is no one right answer, only opposing forces that have to be reconciled.

Really? I thought this was a mostly solved problem. I certainly see it as such when I use modern packaging systems that were developed almost two decades ago.

> I certainly see it as such when I use modern packaging systems that were developed almost two decades ago.

I'm not sure if you have something specific to say about the nuget package management system; how it was used to deliver packages in .Net core and how and why the strategy has changed from delivering the framework as lots of small packages to delivering it as few larger packages; or if you are just being flippant and ignorant.

I would certainly go with ignorant. I stay away from Windows and, in consequence, from .NET. I've heard about NuGet, but I haven't used it, so I don't know if it is any good.

On the other hand, I've seen both strategies (large and small packages) in use, and the better dependency resolution mechanisms and package building tools, the better small packages work. I don't need to install plethora of GNOME and Python packages, I just run `apt-get install exaile' and have it installed. From programmer's perspective this works equally well; I may want to include some specific part of Boost library, but I can also run `apt-get install liboost-all-dev' and be done, and leave detecting the actual dependencies to package builder's tooling.

NuGet is okay, in my opinion. My two biggest issues with it aren't actually issues with NuGet, but with the surrounding ecosystem.

First is that MSBuild hard-codes references, so building a multi-targeted project with references to a multi-targeted NuGet package is a nightmare. From what I've read in the documentation, Paket (an alternative package manager) is supposed to be designed to help with this, but it was already enough of a struggle to introduce NuGet at my work, and NuGet is "built-in" to Visual Studio.

Second is the fragmentation of the .NET frameworks, a la this article. Combined with how .NET makes native interop fairly easy (i.e. platform dependent packages), you get either bloated monolith packages or a proliferation of satellite packages.

Other than that, I've had a fairly easy and straightforward time with NuGet. But then again, I've never seen a project with more than a dozen or so dependencies, compared to using Maven in Java where you pull in dependencies like hotcakes.

I'm split. I'd love to see the churn settle down so the surrounding ecosystem can mature. On the other hand, there are definite pain points with the existing tooling. I remember seeing declarative package references as a feature request for Roslyn, which would be absolutely wonderful, but even if it's released fairly soon, it's probably going to take years for adoption to spread.

> First is that MSBuild hard-codes references, so building a multi-targeted project with references to a multi-targeted NuGet package is a nightmare. From what I've read in the documentation, Paket (an alternative package manager) is supposed to be designed to help with this, but it was already enough of a struggle to introduce NuGet at my work, and NuGet is "built-in" to Visual Studio.

This has changed radically with Visual Studio 2017 and the newer MSBuild tooling. See https://github.com/khellang/Scrutor/blob/master/src/Scrutor/... for an example. It has three targets with both conditional and common package references.

> Second is the fragmentation of the .NET frameworks [...] [you get monoliths] or a proliferation of satellite packages.

And I don't see why "proliferation of satellite packages" is supposed to be bad. It works in Debian's APT, including development packages. Maybe somehow NuGet is not okay, after all? Certainly something is different between the two.

> I would certainly go with ignorant. I stay away from Windows and, in consequence, from .NET.

Right, so what specifically are you adding to today's discussion? What drew you to it?

You claimed that "there is no one right answer" to distributing code (or so I understood), which is false, because it works well in the world outside Windows.

What specifically would you change about Nuget?

All these problems to save a 20MB download.

That's just looking at the tip of the iceberg, I think. It also improves everyone's ability to patch their applications, although with VM and container automation, it's not as big of a deal anymore.

That's actually one thing I don't understand. Having a full framework installed on the machine means all the modules will be updated the .net framework. Shipping with your own binaries means you will need to do the upgrade yourself. That's fine if you have an active team maintaining the application. But in the real world there are many many apps and websites developed once and rarely upgraded. These will not receive security patches if they shipped with their own binaries. I am not convinced this is a benefit.

Your real world is not necessarily the same as everyone else's real world, and in some cases there is great benefit in being able to say "I am going to update the app that I own, and I can guarantee that it won't affect the app that you own, because they both ship with their own binaries, not a shared, system-wide framework."

There are other cases e.g. using EC2 Vms in AWS where it's moot; machines come and go, there is only ever one app per machine. So installing per machine or per app are both 1 install, except that the per-app install has the potential to be slimmer not 1-size fits all.

In short, it's more friendly to new scenarios involving clouds and containers.

And I can see how that will be useful in the case of an active team deploying a service continuously. But I am ready to bet it will also be used (because it's the cool new technology) by lots of people who will create something, perhaps with the intention to maintain it (or not) then move on, and that's how you end up with unpatched software online and sensitive data leaked.

Have you tried the new SPA templates? https://github.com/aspnet/JavaScriptServices

They're better at "download this and everything will work" than any equivalent I've found in the ecosystem for other languages (though elixir/phoenix is there, too). I'm impressed (as a .net newcomer).

With postgres support through npgsql, I'm doing my latest side project in C#. We'll see how it goes.

When an upgrade breaks the ecosystem without that breakage being discussed and announced along with future plans, then .Net is not very good, is it?

I don't think this has anything to do with .NET being good or bad. The issue is completely orthogonal.