> “ .NET's ecosystem uses binaries as the primary exchange mechanism. This solves various problems, especially shielding the consumer from having to replicate the build environment. It's also what enables the multi-language ecosystem.”
And then
> “ However, one largely unsolved problem is the link between source code and binaries. While a significant portion of packages on nuget.org are open source and often link to the GitHub repo, there is no way to ensure that the source code being pointed too actually matches the binaries submitted to nuget.org.”
If the goal of .Net 6 is to defragment the .Net ecosystem then why would you still have to shield developers from a build environment? The multi-language argument is weak too.
Developers should be able to publish source code to nuget instead of binaries as an alternative. Rust managed to achieve this and that doesn’t even have a common intermediate language to protect itself from hardware differences.
Instead, we have to endure this horrible code signing nonsense which is just security theatre, especially for small published open source libraries.
I'm not trying to be that guy, but NuGet.org is littered with bad packages, and it's hard to see, at a glance, what packages are commercial, trials, or open source. Some packages are not even .NET packages.
The default search scoring could also benefit from some work as old, unmaintained, packages often show up on the first page.
I wish there was a way to filter by license, open-source, and/or source-code-package.
I've been a .net guy ever since C# was called COOL and I even went to Redmond back in the days as part of the early adopter program. I'm worried about the adoption and I think it's mainly because of the perceived low quality when it comes to browsing NuGet.org
Compared to npmjs.org, NuGet.org could be soooo much better.
> NuGet.org is littered with bad packages, and it's hard to see, at a glance, what packages are commercial, trials, or open source
True, but on the other hand, there are some areas where NuGet is better than npm. For example:
- Backwards compatibility is more common in the .NET world.
- .NET libraries tend to reinvent small wheels rather than adding a new dependency. I feel like npm has gone too far with the "don't reinvent the wheel" concept.
the biggest problem are that there are thousands of garbage closed source/commerical packages. basically only a few good oss packages out there. and sadly some good oss packages moved to commerical licenses (I can understand that) but it's sad that something like epplus started to be a commerical thing.
the thing is java has the apache foundation which publishes so much great libraries for java. dotnet misses something like that. I mean dotnet basically has no good pdf library like pdfbox. of course there are thousand commerical vendors but some of them are either bad, some have stupid pricing (itext, lul) or don't have modern features and basically are only money grab.
the good thing is, is that microsoft provided tons of libraries upfront and that linking with native code is simple.
Regarding building from source, ~8 years ago, I built Mono, Monodevelop and their dependecies from source on Linux, no binaries, and it was straightforward. Created a language plug-in for a custom language, and I loved the dev environment. Shout out to the Mono community! (And thank you!)
Unfortunately, today, I can't figure out how to build that stack from source, even Gentoo's dotnet overlay can't seem to build it. Oh well. I'd appreciate any pointers.
C# is nearly 2 decades old, and was intended to compete with Java, however it failed on the "write once run anywhere" and the "write once compile anywhere". Microsoft always had a Windows first attitude. Porting a project from Mono to .Net core was hell, and since Mono’s future was uncertain we ended up writing it in C++!
I also see a similar outcome for Swift outside of the Apple ecosystem.
But dotnet core isn’t at all Windows dependent. I definitely wouldn’t have wanted to port to it from
mono, and still don’t like having to port even relatively modern .NET framework code at this point, but for me everything is written to run on Linux in production. Most people develop on Windows (some with WSL2) and some on Mac, and no one has issues for the most part with platform stuff.
There's a lot to hate about dotnet -- The lack of documentation on how to configure .csproj properties without the VS GUI, how convoluted and opaque everything is, the sketchiness of nuget, etc. ad nauseum. It just smells like Microsoft.
But I love love LOVE how much it is used in commercial/enterprise software!!! I can fire up ILSpy/dnSpy and get an easily readable csharp disassembly from basically anything. It makes reverse engineering such a joy! For this reason dotnet has become my #2 language over the past few years.
10 comments
[ 2.3 ms ] story [ 40.4 ms ] threadAnd then
> “ However, one largely unsolved problem is the link between source code and binaries. While a significant portion of packages on nuget.org are open source and often link to the GitHub repo, there is no way to ensure that the source code being pointed too actually matches the binaries submitted to nuget.org.”
If the goal of .Net 6 is to defragment the .Net ecosystem then why would you still have to shield developers from a build environment? The multi-language argument is weak too.
Developers should be able to publish source code to nuget instead of binaries as an alternative. Rust managed to achieve this and that doesn’t even have a common intermediate language to protect itself from hardware differences.
Instead, we have to endure this horrible code signing nonsense which is just security theatre, especially for small published open source libraries.
The default search scoring could also benefit from some work as old, unmaintained, packages often show up on the first page.
I wish there was a way to filter by license, open-source, and/or source-code-package.
I've been a .net guy ever since C# was called COOL and I even went to Redmond back in the days as part of the early adopter program. I'm worried about the adoption and I think it's mainly because of the perceived low quality when it comes to browsing NuGet.org
Compared to npmjs.org, NuGet.org could be soooo much better.
True, but on the other hand, there are some areas where NuGet is better than npm. For example:
- Backwards compatibility is more common in the .NET world.
- .NET libraries tend to reinvent small wheels rather than adding a new dependency. I feel like npm has gone too far with the "don't reinvent the wheel" concept.
the thing is java has the apache foundation which publishes so much great libraries for java. dotnet misses something like that. I mean dotnet basically has no good pdf library like pdfbox. of course there are thousand commerical vendors but some of them are either bad, some have stupid pricing (itext, lul) or don't have modern features and basically are only money grab. the good thing is, is that microsoft provided tons of libraries upfront and that linking with native code is simple.
Dotnet has the Dotnet Foundation which does exactly that.
Unfortunately, today, I can't figure out how to build that stack from source, even Gentoo's dotnet overlay can't seem to build it. Oh well. I'd appreciate any pointers.
I also see a similar outcome for Swift outside of the Apple ecosystem.
But I love love LOVE how much it is used in commercial/enterprise software!!! I can fire up ILSpy/dnSpy and get an easily readable csharp disassembly from basically anything. It makes reverse engineering such a joy! For this reason dotnet has become my #2 language over the past few years.