There are a couple of reasons. First of all one may be interested in a library to manipulate ELF files which is not a wrapper (and therefore does not depend) on libraries such as libelf or libbfd. Additionally, ELFSharp aims to provide a coherent and write-less-do-more interface to manipulate ELFs. Find your way to the examples page to find out whether it succeeded.
For the moment you are able to explore 32-bit and 64-bit, little and big endian ELF files. You can:
You can also list the properties and extract the image from the U-Boot image. The best way to find out is probably exploring the API.
Yes, it is in many aspects. It is free of charge, you can obtain the source code and modify it as you like. You can also use it any way you want. The only condition you have to fullfil is to keep the copyright notice in the source and provide it with the (modified) source code or binary.
That's fine! A better API means that the library will serve its purpose better. Please create an issue on GitHub which describes your idea.
The best you can do is to create an issue on GitHub, which should preferably contain information which can lead me to reproduce it on my machine. Still better if you can propose a solution and ideally, you can make it a pull request rather than an issue.
Absolutely. In fact, it is developed on that OS, which should be no surprise.
Yes, it is pure managed code which does not depend on any native libraries.
You have to use at least Mono 2.8. However a much better idea is to obtain a more recent release, like 3.x. Development (and testing) is done on the most recent version, usually also on GIT head.
If the fields you like to explore are identical for the 32-bit and 64-bit formats, then you don't have to care which one you are exploring. On the other hand, if you want to e.g. get the load address, you have to explicitly state the length of such field. See the examples for clarity.
That's a good question! In fact, some specifications (like one here) say clearly that in 64-bit files NOTE entries occupy 8 bytes. This can't be, however, found in 64-bit ELF files I have encountered. Also there is only one structure for this section in the BFD library. Additionaly, you can find different specifications saying different things. This one is particularly interesting, as it is consistent with the approach I have chosen. Nevertheless, if you ever encounter a 64-bit ELF behaving in a different way, just create an issue on GitHub.