Bug: Serialization fails on Deserialize<Money> (JavaScriptSerializer) about nodamoney HOT 6 CLOSED

We have a lot of unit-tests, but for serialization there weren't any yet (was on the todo list ;-)). Thanks for the report, will fix it asap and create unit-tests for them.

Concerning the ToString() method. It will format Money in the current culture. If you want to format it in the culture of United States, then you should do the explicit (see https://github.com/remyvd/NodaMoney, the formatting area for examples.).

If you still think its wrong, what is the culture you are using and what do you expect in that culture? We are using the formatting that CultureInfo in .NET gives us.

from nodamoney.

Yeah, about the CultureInfo, it's true that I don't have en-US as default. :)
I was just staring blindly at your example where is said it used en-US implicitly from the current culture, only I missed "current".

from nodamoney.

Added unit-test and support for the following serializers: XmlSerializer, DataContractSerializer, DataContractJsonSerializer, Newtonsoft Json.NET & JavaScriptSerializer

NodaMoney has now a dependency on Json.Net, to support it. It's used a lot, so I took the risk to have a dependency on it. If needed this could be a separated library.

JavaScriptSerializer can only be supported by a new library NodaMoney.Serializer.AspNet. You can download the code and compile this. I will create a nuget package in the upcoming release.

You can use it by registering it, like the example below:

// create a new serializer and tell it about the NodaMoney converter.
serializer = new JavaScriptSerializer();
serializer.RegisterConverters(new JavaScriptConverter[] { new MoneyJavaScriptConverter() });

from nodamoney.

FYI - in Noda Time, we split out the JSON serializer into a separate assembly with its own nuget package. XML serialization was left in the main library.

Really though, I wouldn't bend over backwards for JavaScriptSerializer or DataContractJsonSerializer. Almost everything uses JSON.Net now. (IMHO)

from nodamoney.

Your right about for JavaScriptSerializer or DataContractJsonSerializer. Creating an own nuget package is maybe to much effort for this. it's only one class
MoneyJavaScriptConverter.cs at the moment, that people could copy or create themselves and include in their own projects, if they really need it.

I was doubting to have the Json.NET serialzier in a seperate assembly and it's own nuget package, but as you already mentioned, it's used everywhere so I took the risk by depending on it. I think people using RavenDB and MongoDB would benefit from this (need to check this).

It's not yet version 1.0, so I can pull it apart if it's not the right decision. Do you know of any other downsides, apart from a dependency, that made Noda Time to put it in a separate assambly?

from nodamoney.

The dependency was the biggest thing. There are plenty of NodaTime consumers that only use it in their business logic, and thus don't need serialization. We thought it was safe enough to support XML though, since we only have to take a dependency on System.Xml from the framework.

WRT RavenDB, it was important to write a custom implementation so that the Noda Time types could be used in entities, indexes, and queries. I haven't done a MongoDB one yet, but it's on my list.

from nodamoney.