What is the purpose?

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.

What are the current capabilities?

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.

Is the library free?

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.

I have an idea how to improve the API!

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.

I have found a bug in the library.

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.

Does the library work on Linux?

Absolutely. In fact, it is developed on that OS, which should be no surprise.

Does the library work on Windows?

Yes, it is pure managed code which does not depend on any native libraries.

Which version of Mono is required?

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.

How should I handle 32-bit and 64-bit ELFs?

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.

Why is the format of the 32-bit NOTE section identical to the 64-bit one?

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.