Is it OK to switch to Profile151?

[corliss]

Currently SharpFont and SharpFont.HarfBuzz and portable class libraries that target Profile111, which supports the following (taken from http://danrigby.com/2014/04/16/xamarin-pcl-profile-notes/ )

Profile 111 (.NET 4.5, Windows 8.0, Windows Phone 8.1) (netstandard 1.1)

Supported in Xamarin for Visual Studio 2.0+
No WCF (Due to WP8.1 support)
Access to (but not available in profiles 259, 344, 78, or 158):
Parallel Tasks
Parallel LINQ
Concurrent Collections
System.Net.Http
System.Numerics
System.IO.Compression

I'd like to switch to Profile 151, because it supports the generic version of Marshal.PtrToStructure<T>(). (I had to roll back the fix to Robmaister/SharpFont.HarfBuzz#8 because of this.) Here's what Profile 151 supports:

Profile 151 (.NET 4.5.1, Windows 8.1, Windows Phone 8.1) (netstandard 1.2)

Supported in Xamarin for Visual Studio 4.1+
This is a slightly updated version of Profile 111
Several assemblies updated to newer versions
System.Diagnostics.Tracing
System.Runtime
System.Runtime.InteropServices
Access to System.Threading.Timer which isn’t available in Profile 111

Both profiles are supported by the Xamarin platforms. So, is there any reason why we can't update the profile to Profile151?

Cheers

[Robmaister]

Yup, totally fine to move this up, don't see any problems arising from this

[HinTak]

FWIW, I am still mourning the loss of .net 2 compatibility with SharpFont 4.x, and therefore I will not be upgrading to SharpFont 4.X for my project any time soon. Keeping a fork of SharpFont 3.X indefinitely seems easier.

[Robmaister]

On the other hand, it is trivial to provide a static function that is a generic version of Marshal.PtrToStructure. In fact, I'm fairly certain I did this a while ago prior to the PCL support in a static PInvokeHelper class or similar.

The link you took the descriptions from states that profile 259 is the most common, but we're doing P/Invoke, which is unavailable on Windows Phone Silverlight 8.1, so profile 111 is the most compatible profile we can offer.

I think I'm actually going to flip my stance on this - with a single function call that can easily be wrapped, I don't think it's worth it to upgrade and lose some amount of compatibility. I'll add back my wrapper for Marshal.PtrToStructure.

I would also like to introduce a separate NuGet package for .NET 2.0 compatibility using LINQBridge, which would likely mean a separate project or at least a build configuration with a conditional dependency (I do this to compile against different Vector3 classes in different engines in SharpNav, works pretty well).

The main NuGet package will contain a .NET 3.5 build and a PCL profile 111 build, SharpFont.Compat will contain a .NET 2.0 + LINQBridge build.

Since none of these 3 targets require any source code change, I believe that structuring this as a single project with multiple build configurations would work best, as @corliss has already set up again in #101. Thoughts? Objections?