Avoid the error behavior when you obfuse an assembly that uses a class in the System.Xml namespace in Dotfuscator

Check for symptoms

Create a new project. Windows Form, WPF, or either, is the wpf application.

Write code to use classes that belong to the System.Xml namespace. Here, we use the "XmlDocument" and "XmlNode" classes as follows:

using System.Windows;
using System.Xml;

namespace DotfuscatorTest
{
  /// <summary>MainWindow.xaml の相互作用ロジック</;summary>
  public partial class MainWindow : Window
  {
    public MainWindow()
    {
      InitializeComponent();

      XmlDocument doc = new XmlDocument();
      doc.LoadXml("<a></a>");
      XmlNode node = doc.FirstChild;
    }
  }
}

After building, select PreEmptive Dotfuscator and Analytics from the tools in the menu to start.

Add and build the .exe file that you created.

Then, the build fails with the following error message.

This is not a managed module (C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone71\ja\System.Xml.dll). Build error.

I tried to find out the cause of this error, but i couldn't find a clear answer. Considering that there is no information on the English site and a "ja" in the path of System.Xml.dll, you can assume that it is a unique error other than the English environment.

Workaround

Even though the project references System.Xml.dll for the Windows client, when you build with Dotfuscator, you will reference the assembly to The System.Xml.dll in Windows Phone, so you can force the locally copied System.Xml.dll. To avoid build errors by referring to .

Open the project reference settings and right-click System.Xml and select Properties.

Change the local copy item to True.

When you build in this state, System.Xml.dll is printed with the .exe file.

Open Dotfuscator and add System.Xml.dll with the obfuscated assembly. The obnosperated assembly will now look at the local DLL without referencing the installed framework DLL.

Note that library mode is checked in the System.Xml.dll properties. Without this check, System.Xml.dll may also be obnocized and the referenced class name may be changed. If the class name changes, of course, the application will not be able to start successfully.

If you build in this state, you will complete successfully.

You can make sure that the obnosperated application starts on its own without any problems.

Because the content sweated here is a bit tricky workaround, it doesn't guarantee that it will work for assemblies that you've built. There is no denying that even if the build is successful and booted, it will fall when you perform a particular action, so make sure it works properly before releasing it.

Obstonation, not limited to this System.Xml namespace, is a delicate feature that must be ensured to be consistent. Note that I/O-related relationships, such as using reflection in particular, and interacting with file I/O and external APIs, are more likely to be affected.