MSBuild Task

The Babel MSBuild task is available with any Babel Obfuscator license edition. To use it in an MSBuild project, declare it with a UsingTask element that names the file Babel.Build.dll:

<UsingTask TaskName="Babel" AssemblyFile="C:\Program Files\Babel\MSBuild\Babel.Build.dll" />

Babel.Build.dll is in the MSBuild folder of the installation:

For an installation for the current user, write the path with the LOCALAPPDATA variable, which MSBuild expands. The project then holds no user name and works for everyone who installed Babel the same way:

<UsingTask TaskName="Babel" AssemblyFile="$(LOCALAPPDATA)\Programs\BabelDesktop\MSBuild\Babel.Build.dll" />

Loading the task from its file works on every operating system and with every installer. Babel Desktop writes this element when it saves a project on a machine where the task is installed.

Once the assembly Babel.Build has been referenced, it is now possible to use the Babel task to start Babel Obfuscator on a given target assembly:

<Target Name="AfterBuild">
  <Babel InputFile="$(TargetPath)" OutputFile="$(TargetPath)" />
</Target>

The Babel task defined above will be executed after the build to obfuscate the target assembly, replacing it with the obfuscated one processed by Babel.

The “AfterBuild” target is a well known MSBuild target  defined in the build pipeline and it is typically used to add tasks that will be performed once the build has completed and all the binaries are stored in the build output folder defined by $(TargetPath) MSBuild variable .

For instance, the Babel task mentioned earlier will run after the build to obfuscate the target assembly stored in the $(TargetPath) variable, replacing it with the obfuscated version processed by Babel.

Global Assembly Cache

The Windows MSI package also registers Babel.Build.dll in the Global Assembly Cache. A project that is built only on machines installed with the MSI can name the task by assembly name and version:

<UsingTask TaskName="Babel" AssemblyName="Babel.Build, Version=12.1.0.0, Culture=neutral, PublicKeyToken=138d17b5bd621ab7" />

Version is the installed product version with the revision number set to 0: for version x.y.z.w, write Version=x.y.z.0. The element has to be corrected after every upgrade. The EXE installer does not register the task in the Global Assembly Cache, and Linux and macOS have none.

[!NOTE] If the build stops with error MSB4062, The "Babel" task could not be loaded from the assembly Babel.Build, Version=…, the project names a version that is not in the Global Assembly Cache. Replace the element with the AssemblyFile form described above, or open the project in Babel Desktop and save it.

AfterBuild and Compile Targets

In more recent .NET SDKs, some additional optimization tasks have been introduced that occur before the “AfterBuild” task and after the compilation step, which is carried out during the “Compile” task. The “Compile” task is distinct from “AfterBuild,” which serves merely as a placeholder in the build pipeline, meant to be overridden by external build processes. The “Compile” task is the actual step where compilation occurs, and it cannot be replaced by user-defined tasks.

Because obfuscation needs to be performed after the “Compile” task and before any subsequent optimizations made by the build system, you should integrate the Babel obfuscation task immediately following the “Compile” step. This can be done using the MSBuild target attribute AfterTargets as shown below:

<Target Name="Obfuscate" AfterTargets="Compile">
  <Babel InputFile="$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)" 
         OutputFile="$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)" />
</Target>

This setup ensures that the obfuscation process is applied to the compiled output before any further build optimizations are executed.

It’s important to note that the InputFile and OutputFile properties are not set to TargetPath because, at this stage of the build process, the compiled assembly has not yet been copied to the TargetPath location. Instead, it is stored in an intermediate build folder $(IntermediateOutputPath), which serves as the source for all subsequent build steps.

This intermediate folder contains the assembly and other artifacts produced during the compilation phase, allowing various tasks, including obfuscation, to be performed on the compiled output before the final build is completed. By specifying the intermediate path, we ensure that the obfuscation process is applied to the correct version of the assembly, as it exists before any copying or additional processing steps that might alter the build output.

This approach not only streamlines the build process but also ensures that the obfuscated output is correctly generated and prepared for any further optimization tasks or deployment steps.

Configuring Babel Task

The Babel task provides a variety of properties that can be configured to customize the obfuscation process according to your specific needs. A comprehensive list of these properties is available in the Babel Task Reference section of the documentation. By default, the Babel task only enables symbol renaming, which alters the names of classes, methods, and other symbols in the code to make it more difficult to reverse engineer.

To access more advanced obfuscation features, such as control flow obfuscation, string encryption, and other sophisticated techniques, a valid license is required. Without a valid license, the Babel task operates in demo mode, which is limited to symbol renaming. Additionally, assemblies obfuscated in demo mode are designed to stop functioning after a specific date, as indicated in the build log by the warning code W00000. For example:

Warning [W00000]: This is an evaluation version, the obfuscated assembly will no longer work after 15/08/2024 17:16:27

Obtaining and applying a valid license unlocks the full range of Babel’s obfuscation capabilities and removes any limitations, allowing the obfuscated assemblies to run without expiration.

<Target Name="Obfuscate" AfterTargets="Compile">
  <Babel InputFile="$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)" 
         OutputFile="$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)" 
         ControlFlowObfuscation="goto=on;if=on;switch=on;case=on;call=on;true"
         ControlFlowIterations="3" StringEncryption="hash" 
         ResourceEncryption="true" />
</Target>

This ensures that your application benefits from comprehensive protection features, safeguarding your intellectual property and source code from unauthorized access or tampering.

Build Performance in Visual Studio with Code Analyzers

In Visual Studio, code analyzers are tightly integrated into the development workflow. These analyzers continuously run in the background to provide real-time feedback in the Visual Studio editor, which enhances your coding experience by highlighting potential issues as you type. However, this feature comes with a trade-off: it triggers the build process at every iteration, which can cause performance bottlenecks, especially if tasks like Babel obfuscation are part of the build.

To prevent unnecessary performance overhead, you can modify your MSBuild configuration to ensure the Babel obfuscation task runs only during the full build process (i.e., when you’re actually building the solution) and not during the background design-time builds used by the analyzers. Here’s how you can do it:

<Target Name="Obfuscate" AfterTargets="Compile" 
        Condition="'$(DesignTimeBuild)' != 'true'">
    <Babel … />
</Target>

By adding the Condition=”’$(DesignTimeBuild)’ != ‘true’”, you ensure that the Obfuscate target is skipped during the design-time builds (the background processes that code analyzers use). This change will significantly reduce the amount of CPU time consumed during regular coding sessions without affecting your final build process. The obfuscation will still run when needed—during the actual project build.

Babel Task And Babel Obfuscator NuGet Package

The Babel Obfuscator NuGet package available with the Ultimate edition simplifies the integration of the Babel task within the build pipeline. Once the package is referenced in a .NET project, it automatically integrates the Babel task at the appropriate point in the build process without requiring manual configuration. This means that developers do not need to explicitly add the Using directive for the Babel task or manually insert the Babel task into the build script.

The package intelligently determines the correct placement of the Babel task based on the project type and the .NET SDK version being used. This automation ensures that the obfuscation process occurs at the optimal stage in the build pipeline, accommodating various build configurations and requirements specific to different project types. This streamlined integration minimizes the potential for errors and makes it easier for developers to apply obfuscation without in-depth knowledge of the build pipeline’s intricacies.

Key benefits of using Babel Obfuscator NuGet package

1. Automatic Handling: The Babel Obfuscator NuGet package is designed to intelligently manage obfuscation during the build process, ensuring that it runs only during full builds and is skipped during design-time builds used by analyzers.

2. Reduced CPU Load: By automatically skipping the obfuscation step during background builds, the package helps maintain system performance, reducing unnecessary CPU load and allowing Visual Studio to run more smoothly during development.

3. Simplified Configuration: You don’t need to manually modify your MSBuild scripts. The package integrates seamlessly with your project and handles everything in the background, saving time and reducing complexity.

4. Consistent Results: The obfuscation process is consistently applied only during the final build stages, ensuring that your code is protected without interfering with the day-to-day development process.

Additionally, the Babel Obfuscator NuGet package maintain consistency across projects, ensuring that all necessary steps for obfuscation are correctly implemented regardless of the project’s complexity or the team’s familiarity with the process. This feature is particularly beneficial in larger projects or teams where maintaining uniform build processes can be challenging.