[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) . 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 |