CleanupCode Command-Line Tool

--profile — a code cleanup profile that lists cleanup tasks to execute.

By default, CleanupCode will apply code cleanup tasks specified in the Built-in: Full Cleanup profile, that is all available cleanup tasks except updating file header.

There are two more built-in profiles — Built-in: Reformat Code, which will only applies code formatting preferences and Built-in: Reformat & Apply Syntax Style, which applies code formatting preferences and code syntax styles. To use one of these profiles or any custom profile, pass the profile name via the --profile parameter, for example: --profile="Built-in: Reformat Code" YourSolution.sln.

--include/--exclude — relative path(s) or wildcards that define the files to include/exclude during the cleanup. If both --include and --exclude are defined and cover the same set of files, --exclude will have higher priority.
To specify multiple paths or wildcards, separate them with the semicolon or use the --include/--exclude parameters several times.

--properties — lets you override MSBuild properties. You can set each property separately (--properties:prop1=val1 --properties:prop2=val2), or use a semicolon to separate multiple properties --properties:prop1=val1;prop2=val2.

Note that the semicolon cannot be used inside values, for example: --properties:ReferencePath="r:\reference1\;r:\reference2\". In such cases, add each value separately using another --properties parameter — the values will be combined.

The specified properties are applied to all analyzed projects. Currently, there is no direct way to set a property to a specific project only. The workaround is to create a custom property in this project and assign it to the desired property, then use the custom property in CleanupCode parameters.

--toolset — use this option to specify the exact MSBuild version. For example 12.0: --toolset=12.0 By default the highest available MSBuild version is used. This option might not work if you have several installations with the same version, for example 16.0 from Visual Studio 2019 and 16.0 from .NET Core 3.x.

--toolset-path — use this option to specify the exact path to MSBuild. This might be helpful if you have a custom MSBuild installation and want to use it with CleanupCode, for example: --toolset-path="c:\tools\msbuild\bin\MsBuild.exe".

--dotnetcore — by default, .NET Core installation is auto-detected. You can use this option to point to the specific .NET Core installation if the auto-detection results in a conflict. Use it without arguments to ignore .NET Core. Example: --dotnetcore=/usr/local/share/dotnet/dotnet.

--dotnetcoresdk — use this option to specify .NET Core SDK version that should provide MSBuild. For example, if you have installed .NET Core with SDKs 2.0.3 and 3.0.100, CleanupCode will prefer 3.0.100 (the latest, including preview versions). Now if you want to run CleanupCode with .NET Core SDK 2.0.3, add --dotnetcoresdk=2.0.3 to the command line.

--mono — by default, Mono installation is auto-detected. You can use this option to point to the specific Mono installation if the auto-detection results in a conflict. Use it without arguments to ignore Mono. Example: --mono=/Library/Frameworks/Mono.framework/Versions/Current/bin/mono.

--targets-for-references — Names of custom MSBuild targets that will be executed to get referenced assemblies of projects. The targets are defined either in the project file or in the .targets file. Multiple values are separated with the semicolon. For example, --targets-for-references="GetReferences".

--targets-for-items — Names of custom MSBuild targets that will be executed to get other items (for example, a Compile item) of projects. The targets are defined either in the project file or in the .targets file. Multiple values are separated with the semicolon. For example, --targets-for-items="GetCompileItems".

--verbosity — by default, CleanupCode only displays information messages in the log. Use this parameter to change the amount of information written to the log by the following levels (the order is from less to more detailed): [OFF, FATAL, ERROR, WARN, INFO, VERBOSE, TRACE].
For example, if something goes wrong with CleanupCode, you can contact JetBrains Rider support and share a log file with all TRACE messages: --verbosity=TRACE > [path_to_log_file].

--caches-home — lets you specify a custom location for the data that CleanupCode caches. By default, the %LOCALAPPDATA% directory is used, unless there are settings files, in which case the one specified there is used. This parameter can be helpful if you want to use a fast SSD disk for the cache or if you want to store all your build processing data in a single place.

--config-create and --config — these options allow you to pass the parameters described above with a configuration file. The first option will create a configuration file according to the current parameters; the second option is used to load the parameters from this file.

--debug (-d) — use this option to add execution details of CleanupCode to the output. If you have problems with CleanupCode, these details will be helpful when contacting the support team.

--settings — by default, CleanupCode will override its default settings with ReSharper settings from the 'Solution team-shared' layer SolutionName.DotSettings, if it exists. If necessary, you can use this parameter to specify another .DotSettings file, which will override all other settings. For example,
--settings="C:\Work\MyRsSettings.DotSettings".

--disable-settings-layers -dsl — disables specified settings layers. Accepted values: GlobalAll, GlobalPerProduct, SolutionShared, SolutionPersonal

--no-buildin-settings — suppresses settings from global, solution, and project setting layers. Equivalent to --disable-settings-layers: GlobalAll; GlobalPerProduct; SolutionShared; SolutionPersonal; ProjectShared; ProjectPersonal