3 ms·

> “ .NET's ecosystem uses binaries as the primary exchange mechanism. This solves various problems, especially shielding the consumer from having to replicate t

> “ .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.

icanhasjonas 6y ago
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.
- octopoc 6y ago
  > 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.

icanhasjonas 6y ago

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.

octopoc 6y ago
> 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.