Avoid obfuscating assemblies that use classes in the System.Xml namespace in Dotfuscator that will cause errors
Checking the Symptoms
Create a new project. It can be Windows Form or WPF, but here we are creating a WPF application.
Write code to use classes that belong to the System.Xml namespace. Here we use the classes of "XmlDocument" and "XmlNode" 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 and launch it.
Add the .exe file that you created and build it.
Then, the following error message appears and the build fails.
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 what was causing this error, but I couldn't find a clear answer. Considering that there is no information on the English site and that the System.Xml.dll path has "en", you can guess that it is a unique error other than the English environment.
Workaround
Even though the project references the Windows client System.Xml.dll, when you build with Dotfuscator, it references the assembly in the Windows Phone System.Xml.dll so we forcibly copied the System.Xml locally.dll I'd like to avoid build errors by referring to it.
Open the project's references, right-click System.Xml, and choose Properties.
Change the item in the local copy to True.
When you build in this state, "System.Xml.dll" is output together with the .exe file.
Open Dotfuscator and add "System.Xml.dll" along with the assembly you want to obfuscate. This obfuscates the assembly so that it does not refer to the installed framework's DLL and sees the local DLL.
Note that the System.Xml.dll property checks Library Mode. Without this check, System.Xml.dll may also be obfuscated, and the class names it references may change. Of course, if the class name changes, you will not be able to start the application normally.
If you build in this state, it will complete successfully.
You can be sure that the obfuscated application launches on its own without problems.
The content presented here is a workaround in a somewhat tricky way, so we cannot guarantee that it will be effective even for assemblies that have been constructed accordingly. Even if the build is successful and can be started, there is no denying the possibility that it will fall when performing a specific process, so please check the operation properly before release.
Even if it's not limited to the System.Xml namespace, obfuscation is a sensitive feature that you need to make sure that consistency is maintained. In particular, when using reflection, I/O related things such as file I/O and interaction with external APIs are likely to be affected, so be careful.