Obfuscated Uno WASM app not working with reflection-based dependency injection (Autofac and TinyIoC)

[andrewkdci]

This is a continuation of my issue #11985, where @darenm helped me move past the issue of an obfuscated WASM app not showing anything except the Uno logo after loading. (The temporary fix was to disable the linker by adding the WasmShellILLinkerEnabled = false tag to my WASM csproj file, as recommended in the Using the IL Linker article, while the more permanent fix will be to selectively disable the linker on only certain namespaces/types)

To rehash a little from #11985: I am trying to obfuscate the WASM version of a proof of concept app that I wrote. I am using Dotfuscator 6.4 to do the obfuscation on the .clr after publishing the WASM app. I am running the app on Firefox (64-bit, v108.0.2) and on Ubuntu Desktop 20.04.

The app loads and runs fine unobfuscated. However, when I obfuscate it, I get resolution errors from the IoC container. (I have configured my project to use either Autofac or TinyIoC, both of which throw resolution errors, albeit different ones.)

Resolution error when using Autofac:

Resolution error when using TinyIoC:

It seems that Uno WASM still has an issue with reflection-based IoC frameworks. (Not sure if this extends to other reflection-based operations... I will have to research that.)

For reference, here is my Dotfuscator.config, in case it helps at all:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!--This config file was generated by Dotfuscator. Please use the Dotfuscator Config Editor to modify.-->
<!DOCTYPE dotfuscator SYSTEM "http://www.preemptive.com/dotfuscator/dtd/dotfuscator_v2.5.dtd">
<dotfuscator version="2.3">
  <global>
    <input_management>manual</input_management>
    <option>monocompat</option>
  </global>
  <input>
    <loadpaths>
      <file dir="${configdir}/bin/Release/net6.0" />
    </loadpaths>
    <asmlist>
      <inputassembly refid="97021910-dd0a-4131-b651-c1d121573b96">
        <option>honoroas</option>
        <option>stripoa</option>
        <file dir="C:\Users\andrewk\source\repos\Feasibility\Feasibility.Uno.Wasm\bin\Release\net6.0\publish\package_9a5a12e19c0c164c8d55d979136f94d570b63f07\managed" name="Feasibility.Uno.Wasm.clr" />
      </inputassembly>
    </asmlist>
  </input>
  <output>
    <file dir="C:\Users\andrewk\Documents\Documents_Local\VMShared\NginxStaging" />
  </output>
  <renaming>
    <option>xmlserialization</option>
    <excludelist>
      <namespace name="Feasibility.Client.Shared.ViewModels" />
      <namespace name="Feasibility.Uno" />
      <namespace name="Feasibility.Uno.Controls" />
      <namespace name="Feasibility.Uno.Extensions" />
      <namespace name="Feasibility.Uno.IoC" />
      <namespace name="Feasibility.Uno.Views" />
      <namespace name="Feasibility.Uno.Wasm" />
      <namespace name="Microsoft.CodeAnalysis" />
      <namespace name="System.Runtime.CompilerServices" />
      <namespace name="TinyIoC" />
      <type name="&lt;PrivateImplementationDetails&gt;" />
      <type name="__UnoUIRuntimeWasmKeepAlive" />
    </excludelist>
    <mapping>
      <mapoutput overwrite="true">
        <file dir="${configdir}\DotfuscatorReports\${configuration}\${platform}" name="Renaming.xml" />
      </mapoutput>
    </mapping>
    <referencerulelist>
      <referencerule rulekey="{6655B10A-FD58-462d-8D4F-5B1316DFF0FF}" />
      <referencerule rulekey="{7D9C8B02-2383-420f-8740-A9760394C2C1}" />
      <referencerule rulekey="{229FD6F8-5BCC-427b-8F72-A7A413ECDF1A}" />
      <referencerule rulekey="{2B7E7C8C-A39A-4db8-9DFC-6AFD38509061}" />
      <referencerule rulekey="{494EA3BA-B947-44B5-BEE8-A11CC85AAF9B}" />
      <referencerule rulekey="{89769974-93E9-4e71-8D92-BE70E855ACFC}" />
      <referencerule rulekey="{4D81E604-A545-4631-8B6D-C3735F793F80}" />
      <referencerule rulekey="{62bd3899-7d53-4336-8ca2-4e5dbae187d5}" />
    </referencerulelist>
  </renaming>
  <controlflow level="high">
    <excludelist>
      <namespace name="Feasibility.Client.Shared.ViewModels" />
      <namespace name="Feasibility.Uno" />
      <namespace name="Feasibility.Uno.Controls" />
      <namespace name="Feasibility.Uno.Extensions" />
      <namespace name="Feasibility.Uno.IoC" />
      <namespace name="Feasibility.Uno.Views" />
      <namespace name="Feasibility.Uno.Wasm" />
      <namespace name="Microsoft.CodeAnalysis" />
      <namespace name="System.Runtime.CompilerServices" />
      <namespace name="TinyIoC" />
      <type name="&lt;PrivateImplementationDetails&gt;" />
      <type name="__UnoUIRuntimeWasmKeepAlive" />
    </excludelist>
  </controlflow>
  <removal>
    <option>disable</option>
    <removalreport overwrite="true">
      <file dir="${configdir}\DotfuscatorReports\${configuration}\${platform}" name="Removal.xml" />
    </removalreport>
    <referencerulelist />
  </removal>
  <sos />
  <smartobfuscation>
    <smartobfuscationreport verbosity="all" overwrite="true">
      <file dir="${configdir}\DotfuscatorReports\${configuration}\${platform}" name="SmartObfuscation.xml" />
    </smartobfuscationreport>
  </smartobfuscation>
</dotfuscator>

To note:

1. I am only obfuscating the layers below my View Model layer. I am not obfuscating the shared Uno project nor any other non-project, reference code.
2. The advanced settings for the obfuscation are default exception that I set "Use only Mono-compatible transforms" = true.
3. The rest is default. No string encryption, no removal, etc.

Any ideas are appreciated on why this is happening and how to fix it so that I can run an obfuscated Uno WASM app with a DI framework.

[jeromelaban]

It's likely that TinyIoC is not handling some of the renaming of its attributes or types very well. You may be able to look at the code from TinyIOC to determine which attributes or types need to be excluded from obfuscation for the whole resolution to work.

In general, troubleshooting obfuscators issues is done the same way as troubleshooting linker issues, where excluding classes or namespaces progressively can help determine the source of the issue.

[andrewkdci]

BTW, it's odd that Dotfuscator sees all of these secondary classes. It's obvious they originate from the state machines that get generated behind the scenes for async await. However what's strange is that I don't see these extra types when I disassemble via ILSpy.

In any case, here is the above class as seen by Dotfuscator when it's full expanded out:

And here is that same type when disassembled by ILSpy:

Not sure if this is informative at all, or just another red herring.

[andrewkdci]

Okay, I have narrowed down the offending code even more. Now I can get it to work when I comment out all of the RuntimeInformation calls inside the constructor, like so:

        public SystemAccess(IFileAccess fileAccess)
        {
            _fileAccess = fileAccess ?? throw new ArgumentNullException(nameof(fileAccess));

            //if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
            //{
            //    DefaultHwInfoRequest = new HardwareInfoRequest()
            //    {
            //        ProcessorID = true,
            //        HDDSerialNumber = true,
            //        BiosSerialNumber = true
            //    };
            //}
            //else if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
            //{
            //    DefaultHwInfoRequest = new HardwareInfoRequest()
            //    {
            //        ProcessorID = true,
            //        HDDSerialNumber = true,
            //    };
            //}
            //else
            //{
                DefaultHwInfoRequest = new HardwareInfoRequest();
            //}
        }

Now I can include this type in both the renaming and control flow portion of Dotfuscator, and my app will work.

So the question is now: why does a call to System.Runtime.InteropServices.RuntimeInformation break when it's obfuscated?

[jeromelaban]

With regards to IL Spy not showing display classes, this is an expected behavior that you can disable in the ILSpy's options.

As for System.Runtime.InteropServices.RuntimeInformation, You may be able to find out what dotfuscator is doing to this particular type and its call sites (in your SystemAccess) when obfuscation is enabled. It may tell you more about what it's trying to do.

It may also be that dotfuscator has a built-in optimization that breaks on WebAssembly, somehow.

[andrewkdci]

Ah, yes, I see it under "View" in ILSpy. I am now able to see all of the state machine structs that get generated behind the scenes.

[andrewkdci]

I'm marking this original comment by @jeromelaban as the answer. The code that I found that is breaking when obfuscated will actually be refactored out of the WASM app once I do some rearchitecting that I've already been planning for. So although it would be nice to figure out why RuntimeInformation is breaking when obfuscated, and I may still look into it and report back here if I find anything, it's not actually critical to resolving my issue. However it was the suggestion by @jeromelaban to progressively enable or disable renaming and control flow which finally led me to this finding, therefore it's the best candidate to mark as answer for this issue.