Wow, after a 1.6 version I decided to jump straight to 2.0.
Is it that big of a change? Well, not really, maybe a couple of breaking changes and features. But NMoneys 2.0 is just a side dish, the entrée is… NMoneys.Exchange 1.0.

Is NMoneys Already Dead?

Not a chance! NMoneys.Exchange might steal some of its older brother’s thunder for some time, but NMoneys still plays the star role.

Why Another Project?

Well, when NMoneys got its CodeProject article, just about the fist thing people asked was: “Why can’t you exchange currencies?”.

As it is stated in the vision of NMoneys, currency exchange was not in my radar. For one, I did not know the rules for the operations (I still don't) and the data needed is so volatile that companies make money out of providing services around it. So, clearly not a candidate for a library.

But since people asked, I started thinking. Why not? I turned the petition into an excuse to sketch an API… and the result is NMoneys.Exchange, which sits right of top on NMoney’s foundations: Money and CurrencyIsoCode and that will have a whole different lifecycle than NMoneys itself, with different releases, packages, but still close to its older brother.

What’s inside?

NMoneys.Exchange is not more than a framework that allows applying exchange rates to monetary quantities. I will repeat it again: “it’s a framework, not a service”. You need to be a developer to use it, just as you need to be a developer to use a library like NMoneys.

When imported into your project (alongside NMoneys) it offers a couple extensibility points in the shape of the .Convert() and .TryConvert() extension methods over Money. From those extensibility points you can use the provided .To() method that will make things happen.

Is that it? That easy? Then why all the fuss with exchange rates and services and your reluctance to implement it? Well, if you look at it closely it is not doing the right thing, unless the exchange rates between EUR, USD and GBP is 1, which I suspect it isn’t. By default, the framework does no harm, but not the correct thing either. Because correct in this context is not something a library can do, as rates change by the minute.

the trick is providing some exchange rates. How? Either implementing an interface, or using an included implementation of that interface and letting the framework know of it. This example shows how to use the included implementation, include some invented conversion rate and configure that provider:

How does one plug his favorite data feed? Implement a custom IExchangeRateProvider and configure the factory as in the previous example.

As I stated before, I have not become wiser with time and I still do not know the rules for applying rates to monetary quantities. What I have done, in the same extensibile spirit is provide a default implementation that does not harm (or so I believe) using the default decimal multiplication, and leave open the extension of the class that does the work: ExchangeRate. In this example, we subclass ExchangeRate to perform fake custom arithmetic:

If you  want to know more supported scenarios, go to the Quickstart that lives under the project Wiki.

Me Likes. Where?

You can go and get it from the project’s Dowload Area.

It also got its own Nuget package and gem. Download it, use it and do not wait to provide feedback!