[CSHARP-1185] A PCL (or Portable Profile) version of MongoDB.Bson Created: 26/Feb/15  Updated: 03/Dec/20  Resolved: 03/Dec/20

Status: Closed
Project: C# Driver
Component/s: BSON
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Prasanna V. Loganathar Assignee: Unassigned
Resolution: Won't Do Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi,

I was wondering, if a portable profile would be on the cards, and if pull requests would be accepted regarding the same.

I ran through a quick test for portability, currently only MongoDB.Bson of the latest 2.0.0-beta, and found while, not non-trivial, could be quite comfortably made compatible with Win/WP8.1, Xamarin.IOS and Xamarin.Android.

If this is a possible future, then perhaps, a checklist could be started here, for the same.

Things to be done:

1. Change ConcurrentDictionary, and ConcurrentStack with portable implementations (Preferably, from immutable collections) .
2. Some of the IdGenerators have to be adapted. (Eg: AscendingGuidGenerator - ProcessId implementations)
3. IO classes use Serializable Attribute, which is not available. Any practical issues of not using them?
4. Same as 3, for Exceptions
5. Some implementations will have to be moved to a separate, platform specific library, say classes that use IPAddress.

Would like to hear if this a feasible path. Cheers!



 Comments   
Comment by Jeffrey Yemin [ 03/Dec/20 ]

Closing based on Robert's last comment.

Comment by Robert Stam [ 22/Dec/16 ]

I think the need for this has gone away with the introduction of driver support for .NET Core, or more precisely, for any platform that supports netstandard1.5.

Comment by Kristian Loekkegaard [ 10/Mar/16 ]

I am happy to have found that I can achieve what I want with the BsonClassMap instead, thereby avoiding the need to decorate the data classes directly with BSON attributes. I still think it would be nice to have that option in a PCL though, but having the alternative approach available makes it a much lower priority for me.

Comment by Kristian Loekkegaard [ 10/Mar/16 ]

This still seems relevant to me. I have a C# project which contains my data layer – all the domain objects (or entities / POCOs), which will be passed around and used throughout my application, and some of which will also be stored in a database. I have another project in the same solution, which uses Xamarin and references the data layer. Therefore, the data layer project has to be a PCL. I am using MongoDB to store the data on the server side, but because I cannot add the MongoDB.Bson package to the PCL project, I am currently unable to manipulate the way my objects are represented in the database using BSON attributes (e.g. BsonId, BsonRepresentation etc.).

Of course I could write the data layer twice in two separate projects. One for the server side, where I can have the full control over how data is represented in the database using the BSON attributes, and another for the client side, where all the objects would be almost identical, except they are in a PCL project and the BSON attributes are left out. However, that is a lot of code duplication, and ongoing work to keep everything in sync as things change, which I would like to avoid.

Alternative suggestions are very welcome, e.g. if you see another way I could / should be designing and doing this. Otherwise, what is the outlook of getting a PCL version of MongoDB.Bson?

Comment by Prasanna V. Loganathar [ 26/Feb/15 ]

CoreCLR definitely seems like the best-fit road-map. My target was in-fact to figure out if it was feasible to get the serialization library working on mobile devices. Its is a great serialization library - kudos to the team!, and was experimenting if we could BSON for local persistence layers, so we could have a more unified data models both on the server, and across consumer devices. But if targeted for the CoreCLR, should open up most of code to be shared, since Microsoft's strategy is to have the Store Model sitting atop the CoreCLR, and the Xamarin story, should 'almost' automatically be in order with the exception of a few rough edges as long as anything to do with the DLR is tucked away.

Alright, please close this issue, or perhaps change the titles to CoreCLR, as you see fit. Let me try to map out the spectrum next week, that overlaps with getting the serialization libraries running on the WinRT, and the CoreCLR work required. Thanks for the insight on your next step. Would make sense for me to contribute alongside, if the overlap area looks non-intrusive with your next step.

PVL

Comment by Craig Wilson [ 26/Feb/15 ]

Hi Prasanna,

We certainly aren't opposed to this happening, but don't have a good use case, at least for the driver. Talking directly to a database from a mobile application is generally not advisable. Our next step was to work on Core CLR compatibility, which will be more important than PCL for most users.

Perhaps you could share some reasons and use cases where PCL support would be important?

Craig

Generated at Wed Feb 07 21:38:54 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.