Happy New Year to everyone. This “long” silence has given me a bunch of ideas to write about that, by the “magic” of Resolutions will, hopefully, turn into a higher number of entries this year. Enough of it. Let’s talk about NMoneys.
What’s in for the user
Being “small” and focused allows a project to move faster. That means we are able to include the latest changes and deploy them almost overnight. In this case, the Amendment 154 for the ISO 4217 states that from the 1st of January, the currency ZMK with numeric code 894 will become obsolete by the ZMV with currency 967. Said and done, having a method to obsolete currencies makes it possible for users that might be interested in the change, to have it right on time.
Although I believe that the API of the library is small and pleasant enough to use and discover, I am aware of people that love browsing a tree of features (heck, I do something similar myself when decompiling assemblies).
The library has had API documentation ready to be consumed by Intellisense since day one, so it should be easy enough to turn it into MSDN/Visual Studio-style documentation, right? Wrong. It is embarrassing that there is no standard way to achieve such a thing. And no, going though the pain of installing and configuring Sandcastle (or the even less appealingly named SHFB) does not count, it does not.
I will be writing about the process in another post, but as a result of my findings, people can consume 90’s-styled-CHM documentation included in the all the Nuget packages: NMoneys, NMoneys.Exchange and NMoneys.Serialization.Json_NET.
What is not for the average user
The build system for NMoneys was simple enough and based on MSBuild. It worked but…
Why MSBuild? Because it comes out of the box with every .NET installation.
Was it pretty? No, it was not. It was horrible, indeed. It was all my fault. I have always been a NAnt guy that found MSBuild disgusting beyond any desire to learn it.
Did you jump the Ruby wagon? No, taking a dependency on Ruby is too big of a barrier for building such a small .NET project.
One of the reason of adopting MSBuild was that is out-of-the-box. That is also the case with Powershell (sorry, Mono developers out there), so PSake is the chosen one. I will be writing about psake more in future posts; but, for the developer that wants to run the build it is as simple as it was before:
- open a Powershell prompt
- execute an script that will bootstrap psake and runs the build process