Low-level software protection engineer with 20+ years in native and managed code security. Creator of ArmDot, protecting commercial .NET applications since 2014.

.NET Obfuscation in CI/CD Pipelines

ArmDot integrates into standard .NET build pipelines without requiring a separate post-build step, a standalone tool installation on the build agent, or an additional pipeline stage. Two NuGet packages embed obfuscation directly into MSBuild: dotnet build and dotnet publish produce obfuscated output automatically. Protection is configured with C# attributes in source code rather than external configuration files, which means it is version-controlled, refactoring-safe, and visible in code review.

The guides below cover the three most common environments for .NET CI/CD. Each produces a working pipeline configuration by the end.

MSBuild and NuGet integration

Integrating .NET Obfuscation with MSBuild and NuGet →

How the two NuGet packages work, what the MSBuild target does, how to configure protection with C# attributes, and how to pass the license key securely via environment variables. This is the foundation both CI/CD platform tutorials build on.

GitHub Actions

.NET Obfuscation in GitHub Actions →

Complete workflow YAML for Linux and Windows runners, encrypted secret setup for the license key, debug/release build separation, and artifact verification. For indie developers and small ISV teams using GitHub for source control and CI/CD.

Azure DevOps Pipelines

.NET Obfuscation in Azure DevOps Pipelines →

Pipeline YAML for both DotNetCoreCLI and VSBuild tasks, license key management via secure files and Azure Key Vault variable groups, multi-stage pipelines with approval gates, and classic pipeline support. For enterprise teams and organizations on the Microsoft development stack.

Where to start

If ArmDot is not yet in your project: start with the MSBuild and NuGet integration guide. It covers the NuGet packages, the MSBuild target, and the attribute-based configuration that both CI/CD platform tutorials assume is already in place. Without this setup, there is nothing for the pipeline to trigger.

If ArmDot is already integrated and working locally: go directly to the guide for your CI/CD platform. The pipeline-specific setup is minimal - primarily passing the license key through your platform's secrets management - because the MSBuild target handles obfuscation during the normal build without a separate step.

Why there is no separate obfuscation step

Most obfuscators require a distinct post-build step in the pipeline: install the tool on the agent, run it against the compiled output, handle its exit codes separately from the build. This model introduces a specific failure mode - forgetting to add the step, or the step silently not running on a new pipeline or a new project - that results in unobfuscated releases with no warning.

ArmDot's NuGet-based approach eliminates that failure mode. The MSBuild target is part of the project file. Any pipeline that builds the project obfuscates the project. There is no tool to install on the agent, no post-build script to maintain, and no way to accidentally produce an unprotected build while running a normal dotnet publish. The pipeline configuration for an obfuscated build is identical to the pipeline configuration for a normal build, plus a license key.

Back to: .NET Obfuscation: The Complete Developer Guide →

ArmDot in CI/CD

ArmDot runs on Windows, Linux, and macOS build agents with no platform-specific installation. The NuGet packages restore alongside all other project dependencies. Full documentation →. Free trial available - protected assemblies stop working after two weeks.