PCL targeting .NET4.5 (profile111) fails

[tlhintoq]

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?

[mattjohnsonpint]

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:

• You can change your code to target a compatible profile and use the library as-is.
• I could change TimeZoneNames to target profile 136, making it more restrictive - which would reflect the current state better.
• Protobuf could change their target profile to be less restrictive.
• I could rewrite the code to remove the dependency on protobuf.

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.

[tlhintoq]

Thanks for the fast response. I have to admit I'm impressed.

• Not really an option to change profile of my project: Its a Xamarin.Forms solution that works on: iOS, Android, Windows, WindowsUWP. We're using the default profile for a complex multi-project solution like this to ensure the greatest compatibility with other NuGets etc. Basically the thinking is "As long as we stay close to 'out of the box' then failures and compatibility issues aren't on our end."
• You changing the target profile would be more accurate: While more accurate for now doesn't help bring the solution into modern coding times.
• Protobuf changing their target-That would be great for everyone, but to me the project looks abandoned for months. So probably won't happen.
• Removing dependency on protobuf-net. Most work for the most reward.

Looking forward hearing plans/suggestions.

[mattjohnsonpint]

Let's watch protobuf-net/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.

[tlhintoq]

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.

[tlhintoq]

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.

[mattjohnsonpint]

Just released 3.0.0 for .NET Standard support and removal of protobuf. Thus, this is no longer applicable. Thanks.