Closed tlhintoq closed 6 years ago
Basically, this comes down to which profile version you are targeting. Both TimeZoneNames and protobuf are PCLs, and thus can be consumed from lots of different platforms. But TimeZoneNames targets Profile 328 and protobuf targets Profile 136.
Here's a quick reference of the profiles
Since you are using Profile 111 (from your comment on StackOverflow), that profile is compatible with one, but not the other. In particular, 111 includes Windows Phone 8.1, which is in 328 but not in 136.
So really, there are only a few options:
I do plan to eventually remove the protobuf dependency (See #7). It's really only there because it was a quick and dirty way to get the data embedded into a compact format.
Thanks for the fast response. I have to admit I'm impressed.
Looking forward hearing plans/suggestions.
Let's watch mgravell/protobuf-net#166 - but really I'm using protobuf for something other than what it was designed for - so I probably will remove that dependency sooner than later. I'll keep this open for now. Thanks.
Thanks. We can keep an eye on that issue thread but… There are open issues going back go 2014. Looking at all 5 pages of open issues the dates on them seem pretty evenly spread, leading me to think nothing is being done. Otherwise there would be chunks of time missing where the owner took care of a block of things here and there. Hopefully I’m wrong.
I see that Protobuf-net was updated to 2.1.0 on 08july. It still is not profile111 friendly, still only .NET4.0 instead of 4.5, Win80, no .NETCORE etc. Further, I see there is a bug registered as breaking profile136 compatibility. Its nice to see that the project is not abandoned. Sadly there doesn't seem to be any effort to move forward to current technologies.
Just released 3.0.0 for .NET Standard support and removal of protobuf. Thus, this is no longer applicable. Thanks.
This is dependent on Protobuf-net - Which I can't seem to install in a modern 2016 solution's PCL project that targets .NET 4.5 - Any suggestions?