C# friendly API

[buybackoff]

Since it is a general-purpose serializer, it would be nice to avoid FSharp.Core references in C# projects just because of method signatures with optional parameters

[eiriktsarpalis]

I agree, definitely something that must be done.

[eiriktsarpalis]

This has been addressed in the latest nuget release.

See http://www.nuget.org/packages/FsPickler.CSharp/

[ppanyukov]

While this has been addressed by FsPickler.CSharp, I found one tiny issue with that package: the dependency on FsPickler.Json which in turn pulls down Newtonsoft.Json. This may seem like a non-issue for many people however consider this:

• For those who just want a C# façade over FsPickler and never plan to use FsPickler.Json -- why have this extra dependency?
• For large projects with non-trivial dependencies (as we do have) the introduction of Newtonsoft.Json at the level where FsPickler is used may cause issues. We for example had quite a few with Newtonsoft.Json and all sorts of different versions used in different project. For small projects maybe not a problem (just do a binding redirect for example). For large projects may be not so trivial. Lets say that this makes things more difficult.

I personally would prefer the following structure:

1. FsPickler.CSharp:

   FsPickler.CSharp 
      -> FsPickler
      -> FSharp.Core [1]

2. FsPickler.CSharp.Json:

   FsPickler.CSharp.Json
      -> FsPickler.Json
          -> FsPickler
          -> FSharp.Core [1]
      -> Newtonsoft.Json

Or something similar along these lines. The point being that FsPickler.CSharp.Json should be a separate thing IMHO.

[1] The subject of FSharp.Core is a separate one but just to say we've run into some non-trivial VS/MSBuild/F# specific problem with it. Oh well at least it's fun :)

PS. Happy to get together a pull request to separate things if people agree this is a reasonable idea.

[eiriktsarpalis]

Good point, although one of the very next things on my to-do list is to implement the Json readers/writers from scratch. This will remove the Json.NET dependency once and for all from FsPickler.

[ppanyukov]

That would be cool from the dependency point of view. Not sure how everyone will like the idea of "yet another Json reader/writer/whatever" and the fact they can't use their trusted Newtonsoft.Json anymore though.

But does it still make sense to have separate FsPickler.CSharp.Json package? To follow the FsPickler structure:

- FsPickler <-> FsPickler.CSharp
- FsPickler.Json <-> FsPickler.CSharp.Json

[eiriktsarpalis]

If this work is done, there would be only two packages: FsPickler and FsPickler.CSharp.

[ppanyukov]

Ah I see. Yes makes sense :)