Hi guys,
I am looking for a free and open source C# library that can read/write data in spreadsheet format.
License wise, it should be free, open source and would allow me to use it into my plugin which I am going to sell on the Asset Store.
Any suggestions?
Thanks!
CSV files are a human readable format, they are literally just a new line for a new record and commas to separate attributes
You sure it wouldnt be easier to code your own solution for your usage? What do you want it for?
CSV? I could knock something like that in few hours, you probably could do so as well. All CSV really is is comma-separated list of values, where each row of data is separated by ENTER symbol (cr+lf on Windows, lf on mac and cr on linux).
So all you really need is first to read all the lines in the file into array of strings, then use string.split with delimiter set to “,” on each of those to get the values for the individual cells.
Oh wow! Didn’t know it was possible. Just did a small experiment with notepad. Works fine!
Now that I know it’s just data split into commas, yes - it’s something I can make myself 
It wouldn’t be easier to code in your own library instead of using something someone already wrote.
Either way.
Quick 1 second search located this:
https://joshclose.github.io/CsvHelper/
Keep in mind that native csv library will generate garbage and that will bite you on mobile platform.
Everything in C# generates garbage, garbage is bad, and there’s no delete keyword in C#. Because reasons. :-\
Does C# generate garbage even if I just read data? Not write it?
Yes, it is list of comma-separated values, human readable. However, you’ll probably need to handle stray extra whitespaces and possibly quotes. Naive “string.split” approach will faceplant on quotes, definitely.
Lemme recall it.
Calls to string.format generates garbage.
Starting coroutines generates garbage.
Calling delegates in some cases may generate garbage.
Creating any reference type with new generates garbage.
Making a string generates garbage, because strings are immutable.
Any call that returns an array to you generates garbage.
So, you pretty much will always generate garbage.
Juust run the game through profiler and deal with this when it becomes a problem.
Its actually fairly easy to code yourself. We’ve done it, but there is one exception -
The format of a CSV file isn’t the same in every country.
For instance, in the United States, the C in CSV actually does mean using a comma; in France they use a semi-colon instead of a comma (for those of us who live and work internationally it irritates the living daylights out of you :P)
I guess you can’t avoid Garbage Day whether you use a third-party C# Library or code your own solution 
So I might as well code my own solution. For my own experience
You kidding me? 
Well: https://en.wikipedia.org/wiki/Comma-separated_values
So, you can expect to have a tab-separated .csv file.
Heh, nope. So it creates issues when you are on a computer with Excel as US / English and try to open a CSV in the Canada / French or French / French format, or vice-versa. Its a headache.
From a coding perspective, expose a delimiter so its easily changeable and use the delimiter to separate the values being written out or being read in. That way people can easily change the delimiter to suit their country’s format for the CSV file.
It doesn’t matter what they use elsewhere. You don’t need to use CSV format either is you don’t want if a very long record list separated by a comma, a colon, or whatever you choose is what you need.
This is also an issue with JSON. No one parser will treat the period in exactly the same way as all the others. So it creates issues with the format.
We love JSON, but in creating serialized JSON data or middleware that utilizes the JSON format we have to explicitly explain how the JSON parser treats periods.
I guess I should use something more flexible like XLS or XLSX format, which seems to be an XML format document.
Now, that’s news to me. Doesn’t json explicitly define format for every value?
http://json.org/
If middleware can’t properly handle periods, it means they’re cutting corners and use locale-dependent functions for number parsing.
Give different JSON parsers a try
They all may have moved toward treating periods in the same way since we last game them a run through (which was admittedly a while back), but it has been an issue in the past.
How about I ask you instead, since you already dealt with that?
I already answered that question.
Sigh.
Rephrasing.
Which json parsers cannot treat dot symbol properly despite json spec explicitly specifying usage of dot symbol?