Xamarin compat issues with netstandard about standard HOT 6 CLOSED

A bunch of the missing APIs (like all the Marshal.* ones) were added recently and will show up in the latest Xamarin Cycle8 build.

For the other cases, I agree we should take a look if it makes sense to expose/fix them in Xamarin. (Marek and me are both on vacation right now, so expect a bit of delay 😄 )

from standard.

Maybe this isn't the right place, but for System.Security.Cryptography, here's my take:

Definitely cut:

• MembersMustExist : Member 'System.Security.Cryptography.Rfc2898DeriveBytes.CryptDeriveKey(System.String, System.String, System.Int32, System.Byte[])' does not exist in the implementation but it does exist in the contract.
  • We copied this from PasswordDeriveBytes so we could cut it while keeping the method. Then we killed the method because it can't work on UWP or Unix. Since the method still can't work on UWP or Unix, cut it. (It also didn't belong on PasswordDeriveBytes, it just got dropped in there for some reason).

Happy to cut (catalog says there's no usage):

• MembersMustExist : Member 'System.Security.Cryptography.CryptoConfig.AddAlgorithm(System.Type, System.String[])' does not exist in the implementation but it does exist in the contract.
  • Edit: This one has 0.1% usage in the catalog, but I'm still happy to cut it.
• MembersMustExist : Member 'System.Security.Cryptography.CryptoConfig.AddOID(System.String, System.String[])' does not exist in the implementation but it does exist in the contract.
• MembersMustExist : Member 'System.Security.Cryptography.RC2CryptoServiceProvider.UseSalt.get()' does not exist in the implementation but it does exist in the contract.
• MembersMustExist : Member 'System.Security.Cryptography.RC2CryptoServiceProvider.UseSalt.set(System.Boolean)' does not exist in the implementation but it does exist in the contract.
• MembersMustExist : Member 'System.Security.Cryptography.RNGCryptoServiceProvider..ctor(System.Byte[])' does not exist in the implementation but it does exist in the contract.
• MembersMustExist : Member 'System.Security.Cryptography.RNGCryptoServiceProvider..ctor(System.Security.Cryptography.CspParameters)' does not exist in the implementation but it does exist in the contract.
• MembersMustExist : Member 'System.Security.Cryptography.RNGCryptoServiceProvider..ctor(System.String)' does not exist in the implementation but it does exist in the contract.

(Everything else is about sealed v virtual, serialization, or MarshalByRefObject)

from standard.

Thanks @bartonjs I took care of those with 6d04955.

@marek-safar @akoeplinger I've been pruning down the compat issues listed at https://github.com/dotnet/standard/blob/master/netstandard/src/ApiCompatBaseline.xamarin.ios.txt and I'm still working through it but I'd be interested in your guys input on some of them.

1. MarshalByRefObject base class removed from a number of classes.
2. AccessControl APIs it looks like you have a number of them but you also have a number of them removed. I'm going to dig into that entire API surface soon and I'm curious if you can help me understand the logic you guys were using there.
3. Removal of Component as a base class. It looks like you guys remove it from FileSystemWatcher but kept it for things like Process and Timer. Any insights to the logic would be helpful. I'm tempted to remove Component base type from everything that isn't under ComponentModel directly.

There will be other questions those are some buckets I would like to better understand. Also it would be good to understand which set of APIs you guys think you will be adding.

from standard.

1. MarshalByRefObject: XI/XA don't support remoting hence the base type is not useful
2. AccessControl: I think the logic comes from SilverLight but I don't think such APIs are used much in wild if at all.
3. Component: We've added FileSystemWatcher only recently as empty skeleton (throws NIE) so not much time was spent on that type and we always start with smaller dependencies and add more later than the other way. Removing Component from other types would be nice but it's a breaking change.

from standard.

Thanks @marek-safar.

Similar to removing Component removing MarshalByRefObject is a breaking change. I realize we aren't going to support remoting but having the that type doesn't actually cause much in terms of APIs (704c6c5) and we can just make some methods on MarshalByRefObject throw not supported.

from standard.

It's breaking change against .NET FX but not against XI/XA which I was referring to. As you wrote we could add MarshalByRefObject quite easily (throw PNS everywhere) but not sure how useful it'd be.

from standard.