Closed corliss closed 10 years ago
Note: this currently causes issues with the iOS build. As it stands, Eto.Json.Pcl builds on Windows but on iOS with the exact same references the compiler issues an error about duplicate references to System.dll. The temporary workaround is to manually remove the reference to System.dll when testing iOS. But converting Eto.Json.Pcl is the real fix.
Yes, the Json/Xaml functionality is being used. I also have future plans for this such as build tooling to pre-generate code based on the xaml/json to allow building the UI using a designer, but execute code on actual platforms.
I did notice that this was going to be a problem unless it can be converted to pcl directly, unless we turn Eto.Test back into non-pcl. However, I don't think that will be necessary (Json.Net comes with a pcl version).
Eto.Test is already non-PCL; Eto.Test.Pcl is portable. Currently Eto.Json can be tested via the former. And yes there should be no problem making Eto.Json.Pcl portable.
BTW, does Json serialization offer anything that Xaml does not? It seems redundant to have two forms of serialization that both achieve the same thing.
Done.
Curtis, this one's for you. Eto.Json.Pcl currently depends on Eto.Pcl, but is not itself a PCL. Once it is converted, a reference to it can be re-added to Eto.Test.Pcl (which is already a PCL, and therefore cannot reference a non-PCL) and then this line of code can be re-enabled in Test.Sections.Serialization.Json.Test:
Questions: is the Json functionality being used at all? It does add a lot of weight in managing Eto. Why is it a separate dll? Can it be moved to its own repo?