The Knowledge Base section of our website compiles common questions and answers, sorted by product. If you need immediate support and have a current support contract, please contact our support team.
Dotfuscator uses ildasm and ilasm to process the input assemblies. Ildasm is the MSIL disassembler that ships with the .NET Framework SDK. Ilasm is the MSIL assembler that ships with the .NET Framework Redistributable.
Dotfuscator attempts to match each input assembly with the toolset that ships with the version of the .NET Framework that it was compiled with. So Dotfuscator will use the 1.1 versions of ildasm and ilasm on an assembly compiled on the 1.1 version of the Framework; likewise, it will use the 2.0 tools on an assembly compiled on the 2.0 version of the framework.
If Dotfuscator cannot find the version appropriate toolset for an input assembly, it will use a later version if present. It will never use an older version.
You can specify the version of ildasm/ilasm for Dotfuscator to use by adding the following project properties:
Name: ILASM_version, ILDASM_version formatted in the following way: ILASM_v2.0, ILDASM_v2.0
Value: Full path of ilasm/ildasm
If the assembly on which an input assembly depends is not found then Dotfuscator gives the following error while writing obfuscated assemblies: 'External type not found typename, assemblyname, Version=.....'
The solution is to add the directory of the dependent assembly to the User Defined Assembly Load Path.
The option Library mode tells Dotfuscator that the input assembly or assemblies constitute a library. For obfuscation purposes, a library is defined as assemblies that are going to be referenced from other assemblies not specified as one of the inputs in this run.) This has implications for renaming and pruning, regardless of any custom excludes you may have set.
- Names of public classes and nested public classes are not renamed. Members (fields and methods) of these classes are also not renamed if they have public, family, or famorassem access.
- In addition, no virtual methods are renamed, regardless of access specifier. This allows clients of your library to override private virtual methods if need be (this is allowed behavior in the .NET architecture).
- Any user-specified custom renaming exclusions are applied in addition to the exclusions implied by the above rules.
- Property and Event metadata are always preserved.
Pruning (Removal) implications:
- Public classes are not removed, even if static analysis determines they are not required.
- Fields of these classes are not removed if they have public, family, or famorassem access.
- Methods of these classes are not removed if they have public, family, or famorassem access. In addition, such methods are treated as entry points, so their call trees are followed and all subsequently called methods are also protected from removal.
Affected Products: Dotfuscator Pro 4.21 - 4.28.0 VSIP
Cause: Dotfuscator Pro installs PreEmptive.Dotfuscator.Targets to <Program Files>/MSBuild/PreEmptive/Dotfuscator/4, but Visual Studio 2017 has its own MSBuild folder which does not contain PreEmptive.Dotfuscator.Targets. Since the .dotfuproj project refers to a folder inside of $(MSBuildExtensionsPath) which does not exist for the instance of MSBuild being used, the build fails.
To work around this issue pick one of the available fixes:
1) Update to Dotfuscator Pro 4.28.1 (when available) which will install the targets file to the appropriate place.
- or -
2) Modify the following line in the .dotfuproj file
<Import Project="$(DotfuscatorDataPath)\PreEmptive.Dotfuscator.Targets" />
<Import Project="$(MSBuildExtensionsPath)\PreEmptive\Dotfuscator\4\PreEmptive.Dotfuscator.Targets" />
This allows MSBuild to search all MSBuild instances for the targets file. See this MSBuild issue for more details.
- or -
3) Copy the folder
<Program Files>/MSBuild/PreEmptive to
<Visual Studio 2017 install dir>/MSBuild/PreEmptive
- or -
4) Build the Visual Studio project with MSBuild on the command line using the MSBuild installed at