The Autofix plugin leverages LLM tools to fix code violations in your .NET projects running within automated CI/CD pipelines, based on a generated analysis report. dotTEST identifies violations, uses LLM integration to propose fixes for those violations, and verifies each proposed fix to ensure that all issues are fully resolved and no new problems are introduced. Successful fixes result in automatically created commits in the working branch of your project source control repository, enabling manual review and approval before merging.
The dotTEST Autofix Python script is located in <INSTALL_DIR>/integration/aider.
The following are required to use this functionality:
with the following packages:
A valid .NET solution file and an analysis report containing violations.
This feature depends on LLMs, which may produce inaccurate information |
We strongly recommend running the DottestAutoFix.py script inside a Python virtual environment to isolate it from your system-wide Python installation and prevent dependency conflicts.
Follow these steps to set up your virtual environment:
python -m venv venv |
CALL venv\Scripts\activate.bat |
python -m pip install --upgrade pip pip install -r requirements.txt |
The DottestAutoFix.py script can be configured using environment variables or command-line arguments. Command-line arguments take precedence over environment variables when both are specified.
Below is the complete reference for all available configuration options:
| Option | Required | CLI Argument | Environment Variable | Default Value | Description |
|---|---|---|---|---|---|
| LLM API Key | Yes | N/A | %PROVIDER%_API_KEY=<KEY> | - | Your secret LLM provider API key required by Aider. Replace %PROVIDER% with the provider of your choice. Learn more about providers and variables. |
| Solution File | Yes | --solution SOLUTION | N/A | - | Path to the .NET solution file. It must match the solution used for the baseline analysis report. |
| Baseline Report | Yes | --report XML_REPORT_PATH | REPORT=<XML_REPORT_PATH> | - | Path to the dotTEST XML report containing violations to be fixed. |
| Fix Limit | No | --fix-limit COUNT | FIX_LIMIT=<COUNT> | 0 (no limit) | Maximum number of violation fix attempts per run. |
| Max Attempts | No | --max-attempts MAX_ATTEMPTS | N/A | 3 | Maximum retry attempts per violation before stopping. |
| Model Name | No | N/A | MODEL_NAME=MODEL | gpt-4o-mini | AI model for fixing violations (e.g., gpt-4, gpt-4o, claude-3-sonnet). Use aider --list-models <fragment> to see the available models. |
| Weak Model Name | No | N/A | WEAK_MODEL_NAME=MODEL | - | Lightweight model for auxiliary tasks, such as commit message generation. When not specified, it defaults to the specified model name (MODEL_NAME). |
| Tool Home | No | --tool-home DOTTESTCLI_DIR | TOOL_HOME=<DOTTESTCLI_DIR> | dottestcli directory | Path to the dotTEST installation directory (containing dottestcli.exe). |
| Lint Command File | No | N/A | LINT_COMMAND_FILE=<PATH> | lint_command | Path to a custom command file for dottestcli arguments. Only needed if the file is outside the current working directory. See the Lint (dottestcli) Execution Customization section for details. |
| Verification Command | No | --verification-command COMMAND | N/A | - | Command to verify code integrity after each fix (e.g., "dotnet build"). Success is determined by exit code (0 = success). |
| No Source Control | No | --allow-no-source-control | N/A | Disabled | Bypass source control warnings. Use with caution - changes will be made without version control. |
| Help | No | -h or --help | N/A | N/A | Display help information for the DottestAutoFix.py script. |
You can use the provided .env.template file as a starting point to create your own .env file with the necessary environment variables.
The .env file will be searched for in the following order:
CliAutoFix.py fileThis allows you to have project-specific environment configurations by placing a .env file in your project directory, while maintaining a default configuration in the script's location.
You can customize where fix history and log files are stored by setting the PARASOFT_AUTOFIX_DATA_DIR environment variable. By default, the script creates and uses a .cliAutoFix folder in your current working directory to store fix history and logs. If you set the PARASOFT_AUTOFIX_DATA_DIR environment variable, the script will use the specified directory instead. This can be useful for centralizing history and logs, sharing data between runs, or keeping your project directory clean.
Example:
SET PARASOFT_AUTOFIX_DATA_DIR=C:\my\custom\autofix_data |
The Autofix script uses dotTEST CLI (dottestcli.exe) to re-analyze code files after applying fixes, ensuring that violations are properly resolved. You can customize the dottestcli execution by providing a custom command template file.
Copy the lint_command.template file from the Autofix installation directory to your current working directory (where you run the DottestAutoFix script) and rename it to lint_command (remove the .template extension).
Edit the lint_command file to match your project's requirements. The default template contains:
-config "{config}"
-solution "{solution}"
-include "{file_path}" |
You can modify this file to add additional dottestcli arguments such as:
-noBuild for suppressing a build in dottestcli-property for setting custom properties-settings for specifying a custom .properties fileUse a custom location (optional). By default, the script automatically looks for lint_command in your current working directory. If you want to use a command file from a different location, set the LINT_COMMAND_FILE environment variable:
SET LINT_COMMAND_FILE=C:\path\to\your\custom_lint_command.txt |
Before running the Autofix script, we recommend creating a dedicated branch for the automated fixes. This allows you to review and test all changes before merging them into your main branch. |
SET OPENAI_API_KEY=your_secret_open_ai_key |
python DottestAutoFix.py --report ".dottest/report/report.xml" --max-attempts 3 --solution BankExample.sln --tool-home "C:\Program Files\Parasoft\dotTEST\2025.2" |
To ensure accurate results and efficient use of the Autofix plugin, follow these best practices: Generate a new baseline after each Autofix session: Code changes made during the autofix process can alter file line numbers and structure, making the violation locations in your original report.xml obsolete. Regenerate your baseline report to ensure it accurately reflects your updated codebase. Fix history tracking: The script creates data files in the Preserve history: To avoid re-attempting the same violations:
|
After each successful fix, the Autofix script creates a commit in your repository. Since AI-generated code may contain errors or suboptimal solutions, it is crucial to review all changes carefully.
Follow these best practices when reviewing AI-generated fixes:
If you encounter any issues while running the script, ensure that: