Marshal type about standard HOT 4 CLOSED

We should look at usage from NuGet and APIPort to see whether any APIs are affected that have high usage. Our current goal is parity with Xamarin; so we don't need them. However we also want to make porting from .NET FX to .NET Core easier. So I'd say: let's make sure we don't cut highly used ones. Those, we should ask Xamarin to add and throw, if they can't implement it.

We should add the methods on Marshal which means SecureString has to go into the corlib assembly.

from standard.

Another set of interesting APIs on Marshal to consider are the SecureString marshalling APIs.

        public static System.IntPtr SecureStringToBSTR(System.Security.SecureString s) { throw null; }
        public static System.IntPtr SecureStringToCoTaskMemAnsi(System.Security.SecureString s) { throw null; }
        public static System.IntPtr SecureStringToCoTaskMemUnicode(System.Security.SecureString s) { throw null; }
        public static System.IntPtr SecureStringToGlobalAllocAnsi(System.Security.SecureString s) { throw null; }
        public static System.IntPtr SecureStringToGlobalAllocUnicode(System.Security.SecureString s) { throw null; }

For .NET Core we have SecureString implemeneted as a standalone library and have introduced SecureStringMarshal (https://github.com/dotnet/corefx/blob/master/src/System.Security.SecureString/ref/System.Security.SecureString.cs#L26) to break this dependency. To help support this factoriziation I'm thinking we will remove the SecureString APIs from Marshal.

from standard.

@terrajobst @weshaggard @yizhang82

Here is Marshal.SecureString usage stat
SecureString: APIport :4.4% Nuget : 1.9%

from standard.

Reverted the SecureString Marshal removals with 8fc5b7f.

from standard.