Ahh yes. The innate fear of brackets so characteristic of the VB developer. It's one of the few things I WILL poke fun at. I don't believe in "That looks like C, I'm ignoring it". It's a good way to drown. Here's the way it breaks down.

In terms of text formats, MS bet on XML very hard. They did this because they spent a lot of money on tools that worked with a very complex XML-based network programming protocol called "SOAP". It stood for "Simple Object Access Protocol". It was so simple, anyone who could write functioning SOAP code without using some GUI to generate it should be suspected of witchcraft and burned. It's almost impossible to use it without Visual Studio or some other expensive tool managing all the magic for you. Can you imagine why MS might've made such a hard bet on XML?

CSV has been around forever, and doesn't have to use commas. When you were using pipe-delimited strings, you were using a CSV format. It's just "one 'row' of data per line, each 'column' separated by some character". The end. Super simple. Most languages have a CSV parser. Microsoft hid VB's way out in a library they don't include by default, and C# has to use the VB one. Most .NET developers don't even know it's there, because MS puts XML front and center.

Everyone else in the world looked at this and shook their head. The whole reason for using text is so you can debug your protocol easily. Making it so complex you need expensive tools to generate the code goes against that. They noticed JavaScript had a pretty simple object notation. Got an object with a FirstName and LastName property? It serializes to "{FirstName: "Sitten", LastName: "Spynne"}". Easy peasy. There's a parser in every language, and they built a competitor to SOAP called REST off of it. REST is super easy. You can literally write a REST server in 10-15 lines of VB .NET. You're lucky if you can get a SOAP application working with less than a few hundred.

.NET doesn't have any readily-accessible JSON parsers, because MS spent all that money on XML and wants you to believe that <> is easier to read than {}. There is ONE JSON parser in the BCL you can use by including some web libraries, but it's not 100% compatible with how the rest of the world speaks JSON in some weird, subtle ways. So you have to use a third-party JSON parser, and the Netwonsoft one's really good. JSON's what I use if I've got to make stuff that's parsed by both .NET and some other language. XML's what I use if I'm getting paid hourly. I'll use CSV if I've got some reason to not use JSON, but I really like JSON.

That's not the be-all end-all though. Some other formats like INI exist. They have [Sections] and use name=value pairs under those sections. A lot of UNIX config files just use name=value pairs. That looks sort of like CSV, but it can only do one bit of data per line where CSV attempts to fit lots of data per line. .NET doesn't have parsers for these kinds of formats, but it takes less than ten minutes to write one so that's no big deal.

In short, just steer clear of XML. .NET has the best XML parsers in the world. But it's sort of like having the best asbestos insulation in the world.