how to prevent stripping of managed dlls in Unity3d IL2CPP

Question

I am using System.Text.Encoding's 1252 encoding for extended ASCII support to fully utilized the 8th bit of a byte, so far when using Mono as the Scripting Backend, I'll be able to prevent the stripping of the code through Assets/link.xml file like this:

<assembly fullname="I18N">
    <type fullname="I18N.Common" preserve="all"/>
    <type fullname="I18N.Common.ByteEncoding" preserve="all"/>
    <type fullname="I18N.Common.Handlers" preserve="all"/>
    <type fullname="I18N.Common.Manager" preserve="all"/>
    <type fullname="I18N.Common.MonoEncoder" preserve="all"/>
    <type fullname="I18N.Common.MonoEncoding" preserve="all"/>
    <type fullname="I18N.Common.Strings" preserve="all"/>
</assembly>

<assembly fullname="I18N.West">
    <type fullname="I18N.West" preserve="all"/>
    <type fullname="I18N.West.ENCwindows_1252" preserve="all"/>
    <type fullname="I18N.West.CP1252" preserve="all"/>
</assembly>

However, when I switch to IL2CPP, I get the crash as some of the functions has been stripped away during build. Even though I have disabled Stripping Level in Unity's Player Settings..

Here is my runtime crash log:

IL2CPP crash:

NotSupportedException: CodePage 1252 not supported
  at System.Security.Cryptography.TripleDESCryptoServiceProvider.CreateEncryptor (System.Byte[] rgbKey, System.Byte[] rgbIV) [0x00000] in <filename unknown>:0 
  at System.Text.Encoding.GetEncoding (Int32 codepage) [0x00000] in <filename unknown>:0 

Which is the same as in Mono, when I remove the preserve statements in link.xml:

NotSupportedException: CodePage 1252 not supported
  at System.Text.Encoding.GetEncoding (Int32 codepage) [0x00000] in <filename unknown>:0 

Here is how I use the offending code:

byte[] bytes = System.Text.Encoding.GetEncoding(1252).GetBytes(str); // exactly 8-bit

string str = System.Text.Encoding.GetEncoding(1252).GetString(bytes);

Thank you very much in advance!

Answer 1

Actually, you are probably seeing a bug in the IL2CPP runtime which is not related to code stripping at all. With the 4.6.4p3 version of Unity, I can see the same problem, and I've tracked it down. We should be able to get this fixed in the next patch release.

It turns out that an icall in the libil2cpp runtime was interacting with the managed code in mscorlib incorrectly, so the code in mscorlib was sent down a different path for the IL2CPP scripting backend.