Skip to main content

Release Checklist

Use this checklist before you release an application or library protected with Dotfuscator Professional.

Review this checklist when you:

  • Protect an application for the first time.
  • Change your Dotfuscator configuration.
  • Update Dotfuscator to a new version.
  • Change your build or release pipeline.
  • Prepare a protected build for release.

Recommended Development Practices

Use the following development practices to make protected builds reproducible and easier to support:

  • Use a source control system.
  • Use a build artifact repository that can store both publishable and private build artifacts.
  • Use a continuous integration environment that is separate from developer or integrator machines.
  • Assign a distinct version to each release build.

A distinct build version helps prevent confusion between binaries, logs, report files, and Renaming Map files.

Source Files

Treat the following files as source files and maintain them in your source control system:

File When to include it Why it matters
Dotfuscator configuration file, such as DotfuscatorConfig.xml Always Controls how Dotfuscator applies protection.
Renaming Map file, such as Map.xml Only when used as an input for Incremental Obfuscation Helps keep renaming consistent between builds.

Include these files as source files because they control how protection is applied. This helps ensure reproducible builds and lets you track changes to your protection settings.

Review changes to Dotfuscator configuration files the same way you review changes to application source code.

Private Build Artifacts

Treat the following files as private build artifacts:

  • Dotfuscator build output logs.
  • Dotfuscator report files, usually located in the DotfuscatorReports or Dotfuscated directory.
  • Renaming Map files, such as Renaming.xml or Map.xml.
  • Unprotected application or library binaries, if you preserve them.

You can gather these files into an archive and store that archive as a private build artifact.

These files are important because they record which protections were applied to a specific build. They can support auditing, troubleshooting, and post-release investigation.

If you use Incremental Obfuscation, handle Renaming Map files as follows:

Map file How to handle it
Input Renaming Map file Treat it as a source file.
Output Renaming Map file Treat it as a private build artifact.

If you publish protected application or library binaries, treat those files as publishable build artifacts. If you preserve unprotected binaries, keep them private.

Build Integration Checklist

Confirm that your release build meets the following requirements:

  • The build starts from a clean state.
  • Existing binaries and intermediate files are removed before the build.
  • The product is built in Release mode or the intended release configuration.
  • Dotfuscator runs as part of the build.
  • Dotfuscator completes successfully.
  • Dotfuscator configuration file generation is disabled after the initial setup.
  • The build server uses the correct Dotfuscator license.
  • The build server and development machines use the intended Dotfuscator version.
  • Signing completes as expected.
  • The certificate specified in the Dotfuscator configuration matches the certificate used to sign the binaries that users receive.
  • Customer Feedback Program settings match your organization’s policy.

Product Configuration Checklist

Review your Dotfuscator configuration before each release.

Important: Review Enhance Protection After Your First Build periodically to confirm that you are using the recommended protection settings for your application.

Test the Protected Application

Testing the unprotected application is not enough. Always test the protected application before release because protection settings can affect runtime behavior.

Before release, confirm that:

  • The protected application starts successfully.
  • Main user workflows work as expected.
  • Features that use reflection, serialization, XAML, dependency injection, dynamic loading, or configuration-based type names work as expected.
  • Any configured Checks behave correctly.
  • The application handles Check responses as intended.
  • Signing and packaging workflows produce the expected release artifact.
  • Performance is acceptable for your application.

You should also run performance testing when you make significant changes to the application or Dotfuscator configuration.

Protection-Specific Testing

Use the following guidance when testing protection features.

Renaming Checklist

Renaming obfuscation is highly effective, but it can break functionality of an application if a symbol is renamed and a reference to that symbol isn't.

Before release:

  • Test workflows that rely on reflection.
  • Test workflows that rely on XAML.
  • Test workflows that rely on serialization.
  • Test workflows that rely on dependency injection.
  • Test workflows that use configuration files, manifest files, or name-based loading.
  • Confirm that required exclusions are configured.
  • Confirm whether Library Mode is enabled or disabled intentionally.
  • Confirm whether stronger Renaming options are appropriate for your project.

By default, Dotfuscator uses safer Renaming settings. You can configure stronger Renaming options, but stronger settings may require more functional testing.

Control Flow Checklist

Control Flow obfuscation is enabled by default and is low risk for many applications. However, it can affect performance in sensitive areas.

Before release:

  • Test performance-sensitive workflows.
  • Confirm whether any code should be excluded from Control Flow obfuscation.
  • Confirm whether the application needs Mono-compatible transforms.
  • Test the protected app on each target runtime.

If the application must run on Mono, configure Dotfuscator to use Mono-compatible transforms.

String Encryption Checklist

String Encryption is disabled by default and must be enabled for selected areas of code.

Before release:

  • Confirm which methods or code areas use String Encryption.
  • Avoid enabling String Encryption in performance-sensitive areas unless testing confirms acceptable performance.
  • Test workflows where encrypted strings are accessed frequently.
  • Confirm that sensitive strings are protected where appropriate.

For GUI-heavy applications without performance-sensitive areas, broader String Encryption may be acceptable. For other application types, use String Encryption more selectively.

Checks Checklist

Checks run at the locations where Dotfuscator injects them. Use Checks at or near application startup and around sensitive areas of the application when appropriate.

Before release:

  • Confirm where each Check is injected.
  • Confirm the configured response for each Check.
  • Test the normal case.
  • Test the unauthorized-use case.
  • Confirm that custom Check behavior works as expected, if used.
  • Confirm that the selected response is appropriate for the detected condition.

If you use attributes to configure Checks, review the Check Attributes documentation.

Removal Checklist

Removal can reduce binary size and reduce the application’s attack surface, but it can also affect functionality if code is used dynamically.

Before release:

  • Confirm whether Removal is enabled.
  • Confirm whether Library Mode affects what can be removed.
  • Test workflows that rely on reflection or dynamic loading.
  • Test all major application workflows.
  • Confirm whether additional Removal exclusions are needed.

Removal is disabled by default. Enable it only after you have enough test coverage to validate the protected application.

Linking Checklist

Linking combines multiple inputs into a single output. This can simplify deployment and make application structure harder to inspect.

Before release:

  • Confirm whether Linking is enabled.
  • Confirm that Linking is required for your deployment scenario.
  • Test deployment and loading behavior after Linking.
  • Confirm that downstream packaging workflows still work as expected.

Linking is disabled by default. It is not typically necessary for applications that undergo further packaging after obfuscation, such as Xamarin Android apps packaged into .apk files.

Watermarking Checklist

Watermarking embeds a custom string into an application’s structure. You can extract the watermark later to identify a specific build.

Before release:

  • Confirm whether Watermarking is enabled.
  • Confirm that the watermark value identifies the intended build.
  • Confirm that your team can extract the watermark when needed.
  • Confirm that Watermarking is configured in the PreMark section of the Config Editor.

Watermarking is disabled by default.

Report and Map File Checklist

Before release, confirm that:

  • Dotfuscator report files are generated.
  • Report files are archived for the release build.
  • Renaming Map files are archived securely.
  • Access to map files is restricted.
  • Build logs are archived.
  • Archived files are associated with the correct build version.
  • The team knows where to find the correct map file for troubleshooting.

Archived report and map files help you diagnose issues after release. For example, the archived Renaming Map file can help translate an obfuscated stack trace from a released application.

Release Preparation

Before distributing the protected application or library:

  1. Confirm that each applicable checklist item is complete.
  2. Record any checklist item that does not apply and why.
  3. Confirm that the protected build passed functional testing.
  4. Confirm that performance testing passed, if required.
  5. Confirm that reports, map files, and build logs are archived.
  6. Confirm that private artifacts are stored securely.
  7. Confirm that the release artifact is the protected version of the application.

These steps help ensure that you can diagnose issues in the released product, such as translating an obfuscated stack trace with the archived Renaming Map file.

Related Articles

Was this article helpful?
日本語