Yeah, as good as .Net is, they really need to work towards a: "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.
> 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'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.
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.
Right, so what specifically are you adding to today's discussion? What drew you to it?
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.
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.
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.
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.
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.