3 ms·

Unfortunately Nuget package management is abysmal, and a development environment lives and dies by that nowadays. There's also the legacy reliance on XML that s

Unfortunately Nuget package management is abysmal, and a development environment lives and dies by that nowadays. There's also the legacy reliance on XML that shows itself everywhere in C# development. It's easy to forget that the reason Node took off exponentially when it did is not really because it was that great itself, but because NPM (and its' small package philosophy, in combination with JSON based config) was a bit of a revolution in package management that led to network effects of adoption.

tester756 5y ago
>Unfortunately Nuget package management is abysmal, and a development environment lives and dies by that nowadays. are you saying that there should be more packages in nuget? >There's also the legacy reliance on XML. you mean project file? or WPF's XAML?
- ramesh31 5y ago
  >you mean project file? or WPF's XAML? Those, and many other things. XML is just an embedded idiomatic part of the language. There's nothing really wrong with XML, but the web runs on JSON now. And all other modern languages (Go, Rust, NodeJS, etc.) are built with that in mind first.
  - tester756 5y ago
    Well, .NET has Newtonsoft Json which makes working with Jsons pretty easy, the built-in System.Text.Json probably works well too (I didnt use it directly yet) When it comes to XAML, then XML-like structure is way better for describing interfaces than Json After all, the web is built on HTML which's kind of similar.
    - smackeyacky 5y ago
      System.Text.Json is a handy improvement over the Newtonsoft stuff. Faster and has great support for annotating your classes to do things like remove properties that aren't required when you send them externally. A bit painful to move across but well worth it.
  - wvenable 5y ago
    > XML is just an embedded idiomatic part of the language. That's kind of weird to say these days; I never ever deal with XML in .NET. I'd go as far to say it's 1000:1 JSON to XML for me.
  - manigandham 5y ago
    What are the many other things that use XML? And why would these be better with JSON?
manigandham 5y ago
> "Nuget package management is abysmal" Why? Explain more. > "legacy reliance on XML" What reliance? Are you talking about .csproj files? They're very minimal now. XML vs JSON is an old discussion: both are trivial to deal with when small but get unwieldy as they grow (however XML has much better structural support). Also the .NET configuration system reads from JSON files by default.
- Nullabillity 5y ago
  > Why? Explain more. - Why do some packages behave differently depending on whether they were installed from an install or restore command? This shouldn't have any observable difference, sync (restore) should be the only operation that touches the package cache at all. - Opaque reliance on invisible plugin hooks. Back when I had to use it, it was pretty common to get told "oh, just add this random dependency" to fix whatever weird behaviour NuGet got up to that time. Why or how did it fix it? Nobody really seemed to know. - Binary package managers suck. They make your supply chain more vulnerable, and they are an additional repository to set up and manage. And they tend to lead to losing the knowledge of how to do a full source rebuild at all.
  - manigandham 5y ago
    It sounds like you're talking about outdated experiences (on topic with the article). Install/Restore now are the same operation, and all nuget ops are part of the main dotnet CLI which is used by the IDEs and other tooling. No plugins needed because everything is consolidated to the same process. As far as the supply chain, .NET assemblies are IL (intermediate language) and can be inspected and signed to ensure integrity. There are trade-offs but I find it much better than the source-first mess of NPM. Go is interesting but only recently got official module approach and still relies on convoluted path-based references. I don't see how you'd lose knowledge though, you're still building your own source. You can always copy the raw code from an (open-source/decompiled) package into your project and build that way if you really want to.
    - metaltyphoon 5y ago
akdor1154 5y ago
I'd say NPM took off because it was a package manager for a language that barely has a standard library. Framed that way, every new node dev learns how to publish 6 lines of junk to npm.. i guess you could call that a network effect! Nuget is not terrible, its not as simple as npm but not far off. Anything that uses native code is painful, but then so is node-gyp..
- hackerfromthefu 5y ago
  Network effect, notwork effect .. potato, patato!
pelorat 5y ago
NuGet used to be trash, but now with the new project format it's just a single reference.

tester756 5y ago

>Unfortunately Nuget package management is abysmal, and a development environment lives and dies by that nowadays. are you saying that there should be more packages in nuget? >There's also the legacy reliance on XML. you mean project file? or WPF's XAML?

ramesh31 5y ago
>you mean project file? or WPF's XAML? Those, and many other things. XML is just an embedded idiomatic part of the language. There's nothing really wrong with XML, but the web runs on JSON now. And all other modern languages (Go, Rust, NodeJS, etc.) are built with that in mind first.
- tester756 5y ago
  Well, .NET has Newtonsoft Json which makes working with Jsons pretty easy, the built-in System.Text.Json probably works well too (I didnt use it directly yet) When it comes to XAML, then XML-like structure is way better for describing interfaces than Json After all, the web is built on HTML which's kind of similar.
  - smackeyacky 5y ago
    System.Text.Json is a handy improvement over the Newtonsoft stuff. Faster and has great support for annotating your classes to do things like remove properties that aren't required when you send them externally. A bit painful to move across but well worth it.
- wvenable 5y ago
  > XML is just an embedded idiomatic part of the language. That's kind of weird to say these days; I never ever deal with XML in .NET. I'd go as far to say it's 1000:1 JSON to XML for me.
- manigandham 5y ago
  What are the many other things that use XML? And why would these be better with JSON?

manigandham 5y ago

> "Nuget package management is abysmal" Why? Explain more. > "legacy reliance on XML" What reliance? Are you talking about .csproj files? They're very minimal now. XML vs JSON is an old discussion: both are trivial to deal with when small but get unwieldy as they grow (however XML has much better structural support). Also the .NET configuration system reads from JSON files by default.

Nullabillity 5y ago
> Why? Explain more. - Why do some packages behave differently depending on whether they were installed from an install or restore command? This shouldn't have any observable difference, sync (restore) should be the only operation that touches the package cache at all. - Opaque reliance on invisible plugin hooks. Back when I had to use it, it was pretty common to get told "oh, just add this random dependency" to fix whatever weird behaviour NuGet got up to that time. Why or how did it fix it? Nobody really seemed to know. - Binary package managers suck. They make your supply chain more vulnerable, and they are an additional repository to set up and manage. And they tend to lead to losing the knowledge of how to do a full source rebuild at all.
- manigandham 5y ago
  It sounds like you're talking about outdated experiences (on topic with the article). Install/Restore now are the same operation, and all nuget ops are part of the main dotnet CLI which is used by the IDEs and other tooling. No plugins needed because everything is consolidated to the same process. As far as the supply chain, .NET assemblies are IL (intermediate language) and can be inspected and signed to ensure integrity. There are trade-offs but I find it much better than the source-first mess of NPM. Go is interesting but only recently got official module approach and still relies on convoluted path-based references. I don't see how you'd lose knowledge though, you're still building your own source. You can always copy the raw code from an (open-source/decompiled) package into your project and build that way if you really want to.
  - metaltyphoon 5y ago

akdor1154 5y ago

I'd say NPM took off because it was a package manager for a language that barely has a standard library. Framed that way, every new node dev learns how to publish 6 lines of junk to npm.. i guess you could call that a network effect! Nuget is not terrible, its not as simple as npm but not far off. Anything that uses native code is painful, but then so is node-gyp..

hackerfromthefu 5y ago
Network effect, notwork effect .. potato, patato!

pelorat 5y ago

NuGet used to be trash, but now with the new project format it's just a single reference.