Identify Renaming Exclusions – Preemptive Support Center

This page explains how to identify exclusions that need to be configured. While this example focuses on Renaming, you can apply these same concepts to other protection types. The workflow below uses a Xamarin application as an example, but these steps apply to all application types you protect

There are multiple reasons why an application needs to have renaming exclusions. One of the common reasons is some frameworks, for example Xamarin, rely heavily on reflection, which assumes that names of types and members at compile time remain the same at runtime. Dotfuscator's renaming protection applies various rules to ensure proper behavior with these scenarios. As rule improvements are introduced with releases of Dotfuscator, many cases may be handled automatically, especially if you have the latest version of Dotfuscator.

However, there may be some cases that Dotfuscator cannot detect. When this happens, you have to exclude the problematic code items from renaming in order to maintain correct behavior of the app.

The exact renaming exclusions needed vary significantly from app to app.

General Workflow

To configure Dotfuscator's renaming protection:

Enable Renaming. See the Settings Tab for details.
Make renaming exclusions using the Renaming Editor.
Build the Dotfuscator config.
Run the obfuscated app and test its behavior.
Investigate any issues by consulting device logs, exception messages, or other diagnostic tools.
Repeat from step 2 to continue making renaming exclusions as appropriate until the app functions normally.

Detailed Example

The advice above outlines the basics of making renaming exclusions, but it helps to have an example. Here's a detailed set of steps to take to determine renaming exclusions for BugSweeper.Android, the sample used on the Xamarin Getting Started page.

Note that these instructions were written against Dotfuscator Professional 4.33. Newer versions of Dotfuscator may require fewer exclusions for this example.

When you launch the protected BugSweeper.Android app on an Android device, the app runs. However, you notice the text that reports how many bugs are left to find (e.g., "Flagged 2 out of 10 bugs.") is not updating as you play the game:

In the source code you note that the BugSweeperPage.xaml file defines this text using two labels, each with a BindingContext to the board field:

<StackLayout Orientation="Horizontal" Spacing="0" VerticalOptions="CenterAndExpand" HorizontalOptions="Center">
   <Label BindingContext="{x:Reference board}" Text="{Binding FlaggedTileCount, StringFormat='Flagged {0} '}" />
   <Label BindingContext="{x:Reference board}" Text="{Binding BugCount, StringFormat=' out of {0} bugs.'}" />
</StackLayout>

You decide the issue must be due to the BugCount property being renamed. You exclude this manually from the Dotfuscator Config Editor.
You build and redeploy BugSweeper.Android. This time the app runs, and there are no problems when playing, winning, or losing the game.
You commit the change you made to DotfuscatorConfig.xml to local version control.

Extra Tips

With Xamarin, after enabling USB debugging on the phone, open Android device log in Visual Studio to see detailed logs about possible errors. Filter the log down to just Error and Warning for clarity.

If an error occurs inspect the stack trace to locate the source of the error. You may have to cross reference with the renaming map file to discover the original name of the function. For example, given a stack trace as follows:

Caused by: android.runtime.JavaProxyThrowable: System.Exception: Can't resolve name on Element
 at Xamarin.Forms.Xaml.ReferenceExtension.ProvideValue (System.IServiceProvider serviceProvider) [0x000b6] in <cdab8e5cc6744897b152dd4075cc1cb0>:0 
...
 at Xamarin.Forms.Xaml.Extensions.LoadFromXaml[TXaml] (TXaml view, System.Type callingType) [0x00000] in <cdab8e5cc6744897b152dd4075cc1cb0>:0 
 at BugSweeper.BugSweeperPage.b () [0x00000] in <7a7fbb7c3c1f42e59202c72d51d629fe>:0 
 at BugSweeper.BugSweeperPage..ctor () [0x00006] in <7a7fbb7c3c1f42e59202c72d51d629fe>:0 
 at BugSweeper.App..ctor () [0x00006] in <7a7fbb7c3c1f42e59202c72d51d629fe>:0 
 at BugSweeper.Droid.MainActivity.OnCreate (Android.OS.Bundle bundle) [0x0000e] in <bf5a3ea557124c988f94e73e801e2727>:0
...

Based on this stack trace, you can see the error happened in a method named b() on type BugSweeper.BugSweeperPage. As the BugSweeper source code doesn't have a method by that name on that type, you can deduce this must be an obfuscated name. Open the renaming map file (C:\code\BugSweeper\BugSweeper\BugSweeper.Android\DotfuscatorReports\Release\Renaming.xml) and look up the appropriate module (BugSweeper.dll), name (BugSweeper.BugSweeperPage), and method (new name of b):

<mapping>
   <module>
       <name>BugSweeper.dll</name>
       <type>
           <name>BugSweeper.BugSweeperPage</name>
           <methodlist>
               <method>
                   <signature>void()</signature>
                   <name>InitializeComponent</name>
                   <newname>b</newname>
               </method>
           </methodlist>
       </type>
   </module>
</mapping>

The map file indicates the original name of this method is InitializeComponent. This is a good place to start looking for the source of the error.